> 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. No, I was suggesting that this be done manually by maintainers if possible. Given that some maintainers would lack the time, I think it would be beneficial to set up a bug for each package with Python code, assign it to the maintainer, but have a tracking bug so that those interesting in helping out can go through the packages and pick off all the Py3k bugs. > Otherwise we get into a fork situation. The initial switchover does > not concern me so much as a dual maintaince problem. Again, we wouldn't be switching the whole distro en masse, simply providing compat- and migrating as possible. > A new gcc didn't really require that I stop using print() in the source, > it was mostly a build thing, no? Correct. I'm thinking of this more like the patch_fuzz issue introduced by the new version of rpm in F-10. I didn't have a copy of rawhide around, so all my packages got the macro band-aid, and I'll be doubling back to fix them in the next few weeks. > --Michael > -- in your fear, speak only peace in your fear, speak only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
