increasing the python requirement

[Barry Warsaw]

On Jan 04, 2011, at 10:21 PM, Toshio Kuratomi wrote:

><nod>  python3 is an interesting target.  In Fedora, we have parallel
>python2 and python3 stacks even though we don't have parallel python2.4
>python2.5 python2.6 python2.7 stacks.  We consider them separate enoguh
>languages that we need to have both of them.

The same is true for Debian/Ubuntu.

>1) python3 makes releases just like python2 -- so you may ship python-3.2
>compatible code but some distributions may only have python-3.1.  (EPEL5 is
>currently shipping python-3.1 since 3.2 isn't released yet.  python-3.0
>isn't recommended so hopefully you wouldn't have to worry about it.  EPEL
>tries to follow the same release methodology as RHEL so EPEL wouldn't ship
>python-3.2 as it'll break people depending on the python3 package to not
>break compatibility).

The situation in Python 3 is a little different though due to the language
moratorium (PEP 3003).  This primarily covers core syntax, builtins, and
semantics, so it doesn't address all the compatibility issues you'll hit, but
it does help.  I personally think that Python 3.2 is the first version that
folks should consider writing against natively with new code bases, and it
makes a good target for porting Python 2 code.

>> On the other hand, when we come to try that work it might turn out
>> that it's hard to support both 2.6 and 3.x, or on the other hand that
>> supporting 2.5 is no harder than supporting 2.6.  I've seen anecdotes
>> supporting any of these positions so I think the only thing is to
>> actually try it in bzr.
>> 
>I very much agree with you here.  Until someone takes a stab at converting
>the code and testing it under python3 you won't really know what versions
>can be supported.

Yep.  I do fear that there will be a fair amount of yak shaving necessary
though, as you find you need missing support in third party libraries.  That's
really valuable to the community as a whole, but might seem like waste to bzr
hackers.  Still, I think you should budget for a certain amount of porting
and patching work in bzr's dependencies (and even possibly the stdlib).

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110105/e56e038d/attachment.pgp>