Jon Ciesla wrote:
We're just now dealing with Python 2.6, but over on the radar is perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3. I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs a language
designer has lost it that I've seen.
http://docs.python.org/3.0/whatsnew/3.0.html
This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.
(NOTE: this requires the viewpoint that not everyone care just about the
latest Fedora, which might be controversial... but to me, the latest
Fedora is what I'll run as my dev environment but not everyone can
upgrade -- and many folks are also running EL and EPEL deserves our full
support and consideration)
So, what of plans?
Are we looking at also carrying on with packaging 2.N indefinitely when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).
I haven't seen /anything/ regarding a compatibility mode for
/usr/bin/python, and I'd hate to have to develop a non-core library that
allows for functions that work the same way on both versions and use
that instead. That would be heinous.
Short of porting everything over to Ruby, oCaml, or
enterprise-Fortran.NET#4000, any ideas on planning for this?
Well, this:
http://docs.python.org/3.0/library/2to3.html#to3-reference
should be helpful. The work being done on 2.6 now is an excellent first
step.
Other than that, I think we'll have to treat it like any other major
change, such as gcc-4.3, etc.
It's gonna hurt, and obviously we'll need a compat-python26, but I think
we'll be able to port things over, and have them either use Python3k or
compat- as needed. Not sure when we'd be completely cut over, but I'd
love to see 2.6 the default in F11, which I believe is the plan, and Py3k
in the not too distant future*, F12.
--Michael
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
* or maybe next Sunday A.D. :)
You're suggesting running 2.3 at each build time? I hope we can trust
it that much and it knows how to automatically port all possibilities.
Otherwise we get into a fork situation. The initial switchover does
not concern me so much as a dual maintaince problem.
A new gcc didn't really require that I stop using print() in the source,
it was mostly a build thing, no?
--Michael
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
