On Fri, 2008-12-05 at 08:49 -0600, 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? There is no real plan atm. > > 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. It has been requested for us to do dual installs of python multiple times now, and in each case it was voted down. Because with GCC, we just have a second GCC, but with python we need a second version of every module that uses it. Imagine if a second GCC required a second version of every package that required a shared library. We also have _much less_ resources dedicated to python than we do GCC. My guess is that if a second python is proposed for py3k, it'll get voted down again. Add onto that the fact that lots of python code is going to break in 3.0, and the fact that 3.0 seems utterly broken wrt. unicode, from bits I've heard. Then there's the fact that for the next 6-12 months people will want to be developing things that still work with python-2.4.* (as that's what is in RHEL-5/CentOS-5). > 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. hahaha, I'll put money on python3k not being the default in Fedora 12. Hell, I'll even put some money on it not being the default in Fedora 14, at this point. My personal opinion is that we stay with 2.6.* for as long as possible, giving everyone time to dual port and the problems to be found/fixed and then it "should be easy" to have it as a feature and move for one release. But I'll point out that Ignacio Vazquez-Abrams did _all_ the work for 2.6 in Fedora 11 ... so feel free to take this as just my opinion. -- James Antill <james@xxxxxxxxxxxxxxxxx> Fedora -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
