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 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
