On Fri, Dec 05, 2008 at 09:42:43AM -0500, Michael DeHaan 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.
IMHO the only viable option is to maintain both python 2.x and 3.x
in parallel. It is essentially a brand new language which just
happens to share the same base name. Like Perl 5 & Perl 6.
It is going to be a very long time before every upstream for all our
python bits support 3.x syntax and we don't want to have to undertake
the work to re-write them all ourselves.
The delibrate break of syntax is going to cause a major PITA for
upstream projects because there's no way they can stop shipping
2.x compatible code just because some people want to use 3.x. So
every upstream pretty much has to now maintain two sets of python
bindings :-(
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|