The looming Python 3(000) monster

[Jon Ciesla]

> 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 at redhat.com
>>> 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