No subject

reasonably well; for the case where other people run 2to3 - the output
is not dependent purely on the input we supply (the bzr code) but
anyhow; the point was made and supported by Stephen - at least
historically, 2to3 has been a very variable thing.

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

>> - 2to3 means an indeterministic program is actually run
>
> It's an algorithm, it's not indeterministic. =A0There 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.

See above, 2to3 is a moving target, rather like rpython (what it can
handle is rpython, what it can't isn't).

>> - I like to be able to properly support things
>
> Me too, but this is also irrelevant. =A0We can say we support particular
> 2to3 versions in the same way we support particular interpreter
> versions. =A0But more to the point we can get things passing on 3 before
> we commit to supporting anything.

We've had bugs with pyrex output already, and they took more time to
analyse that would have been ideal - because the users pyrex version
output different, unexpected, things. I see this as similar - we have
an open task for someone to start versioning the pyrex files we put in
our tarballs, and that issue is part of it. So again, I don't see this
as irrelevant. It would be irrelevant if the migration and [python
version] support strategy we use had no impact on our ability to
diagnose and solve bugs.

>> - distros would prefer to ship a single 'bzr' package rather than two se=
parate ones - and because they run with precompiled files not writable by t=
he 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.

Stephen says numpy will force such support, but I fear that it will be
spotty, hard on users, and not very nice. It is a similar problem, but
in a different domain (package dependencies) and I can pretty much
guarantee that at least the Debian answer will be 'not pretty'. At
best. Of course this isn't a dominating factor for us, but its worth
thinking about a little.

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

Its quite solvable yes, but using explicit markers - such as the _b() funct=
ion.

>> 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. =A0Additional compile steps are
> not great but not awful, and better than having bad code that you have
> to actually edit.

I think this depends on the degree to which you trust your compile
steps :). I don't have a huge degree of trust in 2to3, based on the
anecdotal evidence of lurking in #python-dev and on the main python
developer list.

> So the course I would like to follow is the one suggested by python.org:
>
> =A0* get things clean with -3

I think that this is good to do regardless.

> =A0* 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

> =A0* 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.

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.

-Rob