Python 3

[Martin Pool]

On 23 June 2010 15:54, Robert Collins <robertc at robertcollins.net> wrote:
> On Wed, Jun 23, 2010 at 2:11 PM, Martin Pool <mbp at canonical.com> wrote:
>
> Meta: I'm not pushing for 3, I did a quick test to see how hard it was
> likely to be; we can stop this conversation and just wait and see, at
> any point.
>
> I'm fine with the steps you're proposing we do now; waiting and seeing
> is a fine strategy, we certainly won't be significantly better or
> worse off if we wait (though we may end up with more time-pressure if
> 3.0 support were to become an important issue in the future for some
> reason).

I think it's good to start getting some back-burner experience with
python3.  If nothing else it may improve the code in the same way gz's
non-cpython patches have.

It seems we have to choose between
 0 - use 2to3 as a compile step, and update the code so that it works
on 2.[456] and 2to3

You may well be right that 2to3 doesn't work well, or doesn't work
consistently across all installations, or leaves enough hard problems
unsolved that it is infeasible to have a single codebase across
2.3..3.1.  In that case we would have to choose between

 1- having one branch written in the common subset of 2.3..3.1
 2- dropping support for 2.4 (or also 2.5) in some bzr series
 3- having a separate 3.x branch

#2 and #3 are clearly possible but a bit unattractive, especially #2.
#0 and #1 may be either impossible or hard.

I'm reluctant to merge ugly or intrusive changes to trunk until we
know that we do want to do #1.  I think we can get closer before
deciding.

>>> - folk will want 3 before there are no platforms that have python2.x and not python3.x support.
>>
>> True but irrelevant
>
> I dispute the irrelevancy; I wasn't clear enough, but AIUI 2to3 only
> helps with 2.6->3.x, so if we still support 2.4, we will have
> significant trouble supporting 3 from a single source tree using 2to3;
> other options like a ported-trunk may work better at that point (and
> the port could be to 2.6 w/2to3 at that stage)

I guess we'll have to see whether there are any constructs where the
only way to spell it in 2.4 can't be translated by 2to3.

>> So the course I would like to follow is the one suggested by python.org:
>>
>>  * get things clean with -3
>
> I think that this is good to do regardless.
>
>>  * get the test suite running under 2to3
>
> No problem with doing that either :- but I do think that close care
> should be paid to the output of 2to3
>
>>  * assess at this point whether we want to support actual use under 3
>> and/or have a separate branch and/or cut over to requiring 2.6 or 3
>
> I'm fine with this too.

Great, let's do this then.

> I really do believe that the dragons under the hood are all going to
> be bytes vs string type related, and that we're going to find out the
> hard way - e.g. by our test suite being internally consistent, but
> externally faulty, due to the test suite getting cast up to string
> too.

Probably.  On the bright side it could make things cleaner to have a
clearer distinction.

-- 
Martin