Python 3

[Stephen J. Turnbull]

Martin Pool writes:

 > 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.

The differences across versions were pretty large in my experience
(all pre-3.1, though; maybe it's more stable now).  You might want to
distribute a particular version with Bazaar to get a reasonably
reliable output.  I'm not sure how much the 2to3 application itself
changes, but the ruleset gets better.

You'd also probably really want to distribute specific customized
rules to handle bzr-ish idioms, anyway.

 > I suppose like for Pyrex we would have the choice of either
 > distributing the converted code or getting people to run it.

I don't think having people run 2to3 themselves is a reasonable idea.
It is not intended to be a Python2 to Python3 compiler the way Pyrex
is a Python to C compiler, at least not yet.  At least at first (ie
during the alpha period when you're still learning about bzr idioms
that 2to3 doesn't handle OOTB and developing bzr-oriented custom
rules), there will need to be some post 2to3 hand-tweaking.  Cf.
Martin van Löwis's Django port and patch (cited by Robert).

 > > - 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.

They're also going to need to do this for other libraries, such as
numpy, and probably a number of applications.  The distros can handle
it.