Python 3

[Martin Pool]

On 23 June 2010 11:42, Robert Collins <robertc at robertcollins.net> wrote:
> 2to3 is indeterministic in the sense that users will have different
> versions of it, with different capabilities.

That's a funny definition of "indeterministic" but anyhow, it's true
they may vary in the same kind of way that people will have different
pythons, kernels, pyrexes, libcs, etc.  What the magnitude of those
differences may be, I don't know.  It first came in to python2.6
afaict so we only have that and then later updates in 3.0 and 3.1.

I suppose like for Pyrex we would have the choice of either
distributing the converted code or getting people to run it.  If we
distribute the converted code then we could fix it to some particular
version.  If we expect the user to run it then perhaps we could say
"bzr is supported on python3.0 using python3.0-2to3".

>
> I think 2to3 is a fine tool for small projects with no serious quirks,
> but we aren't one of those. I enumerated all the issues I see with
> 2to3 earlier in the thread, so I won't repeat that now; but I think
> that they need to be addressed before we can consider using 2to3 for
> anything other than mechanical translation. Fixing things that are
> outside of what 2to3 can do is likely a good idea anyway.

You mention that

> - folk will want 3 before there are no platforms that have python2.x and not python3.x support.

True but irrelevant

> - 2to3 means an indeterministic program is actually run

It's an algorithm, it's not indeterministic.  There may be different
versions with different bugs but I doubt it will be a larger problem
than we've had with other dependencies, and probably smaller.

> - I like to be able to properly support things

Me too, but this is also irrelevant.  We can say we support particular
2to3 versions in the same way we support particular interpreter
versions.  But more to the point we can get things passing on 3 before
we commit to supporting anything.

> - distros would prefer to ship a single 'bzr' package rather than two separate ones - and because they run with precompiled files not writable by the user...

This is going to be complicated for distros, but it's a somewhat
similar problem to needing binary extensions built for different
interpreters, which they can do.

>
> For the bytes stuff I've mentioned - see
> http://bugs.python.org/issue5425 - 2to3 converts str to 'string' not
> 'bytes', so we have to mark up everything, and only Python 2.6
> supports b'foo'. If we change the importer to go to bytes for 'str',
> then we end up with all our literals that are meant for humans as
> bytes, which is also wrong. And while we support < 2.6, we can't
> annotate strings properly for bytes recognition without something like
> a domain specific language - e.g. a _b() function.

This seems like a problem with ever wanting a single codebase to run
across 2.4..3.x, whether you support 3.x directly or by 2to3, but
probably soluble along the lines discussed in the Django page: add a
new clearer marker for "really bytes".

>
> We're a library, with very different concerns about when we stop
> supporting a version of Python to a simple end user application that
> doesn't care about embedding or reuse - and typically ships an entire
> Python stack anyway. AFAICT 2to3 is *entirely* driven by 'hey, you can
> *switch* over easily', not by ongoing maintenance concerns; the 'add
> 2to3 as a compile step in your application' is deeply unsatisfying

The document Barry quoted earlier is not suggesting that you switch,
but rather you run it as a compile step.  Additional compile steps are
not great but not awful, and better than having bad code that you have
to actually edit.

> http://www.slideshare.net/regebro/python-3-compatibility-pycon-2009
> and http://wiki.python.org/moin/PortingDjangoTo3k are interesting
> reads and had some hand in shaping my opinion on this. Note that the
> latter is a patch - you can get an impression of how much stuff 2to3
> *didn't* do there.

Slide 11 and slide 50 suggest libraries develop on 2 and used 2to3 to
support 3.

So the course I would like to follow is the one suggested by python.org:

 * get things clean with -3
 * get the test suite running under 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

-- 
Martin