Michael DeHaan wrote: > > 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. > This is a problem that hasn't been brought up before. We can keep Fedora going on python-2.6, 2.7 (and 2.8 if it occurs) and gradually move code close to py3.x-ish syntax by using the "from __future__ import *" mechanism. But that doesn't help with older distros running python-2.5 or less. I don't believe there's anyway around that, though. As we move to python-2.6+ w/ 3.x features we'll have this problem no matter when we actually move to python-3. So we eventually (unless we hold off on moving to python3 until python-2.6 is standard on all RHEL releases) will be maintaining two trees of code no matter what. If we maintain a python2 package and a python3 package in one version of Fedora we'll have even more work. Right now we can have an EL-5 and Fedora-9&10 package that are compatible with 2.5. A different version can run on Fedora11 with the syntax ported to python-2.6's understanding of what 3.x will be like. If we have both python2-2.6 and python3-3.0 in Fedora11 we'll have to maintain separate py2 and py3 packages for every python module we ship as well. We should avoid this if we can. Note that I think this decision is only partially within the powers of the Fedora Project to decide. If 80% of our upstream libraries move to py3, we'll need to move to py3 sooner. If 80% refuse to move off of py2, we can take our time working on migration code. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
