Python 3

[Stephen J. Turnbull]

Robert Collins writes:

 > Yup. And see recent threads on Python-dev too. Even now, years later,
 > the complete break in Python 3 is still a source of angst.

True, but the "even now" is inappropriate.  This angst was predictable
(though nobody said "we expect much weeping and gnashing of teeth" out
loud that I recall), and *is expected to continue* for at least another
3-5 years as various libraries transition to Python 3 (thus enabling
new generations of app developers to make their own transitions and
start gnashing their teeth as they do).

I commend you personally for your forward-looking spirit.  But Bazaar
as a project shouldn't hurry at this point.

 > It would be nice to avoid that. Perhaps 2.8 or 3.3 could be more
 > compatible?

As Barry says, 2.8 is clearly a dead letter within python-dev, and as
yet I've seen no calls (not even trolling) for a separate project to
do a 2.8.  Of course, 2.7 is a pretty nice language, most libraries
will maintain compatible versions at least on PyPI, so pressure for a
2.8 (from any source) is at least a year away, I think.  It's not
clear what the theme of 3.3 is going to be, but with the ongoing
language freeze, I suspect compatibility efforts would not fare well.

The most common library strategy seems to be supporting two library
versions, with multiple versions of some files and a gradual
refactoring concentrating wrappers for the incompatible interfaces in
a small number of modules.  As Robert proposed in his initial post.
So that's good.

But 2to3 gets better all the time, and I think 3to2 is expected for
3.2?  So it's not at all a panacea, but instead of targeting "one code
base for Python 2 and Python 3", maybe the thing to do is to target
"one code base for Python 2 and 2to3", and try to autogenerate as much
of the Python 3 code base as possible.  Presumably as 3to2 improves,
you should be able to transition that to target "one code base for
3to2 and Python 3".

But what worries me is the Python 2 str vs. Python 3 str set of
issues, because they're hard to flag, let alone automatically
transition.  Do you have a sense for how pervasive that is in the
Bazaar codebase?  Is Unicode usage mostly encapsulated in a few
functions, primarily used in the UI?  Or is it more widespread?  How
about functionality like diff?  Is that affected?

(Again, this isn't something you need to deal with immediately, a
Python 3 transition will take years, but I think it's worth thinking a
little about.)