Python 3

[Robert Collins]

Thanks for the feedback; some data inline below.

On Wed, Jun 23, 2010 at 10:20 AM, Barry Warsaw <barry at canonical.com> wrote:

>>If the consensus from this thread is that this is ok, I'll update
>>HACKING docs appropriately.
>
> HACKING.txt doesn't describe the minimum Python version for which
> compatibility must be maintained.  Perhaps it should?  Maybe it's described in
> a different document?  It does *imply* in a few places that Python 2.4 is the
> minimum version.  Understandable of course, but darn.

perhaps it should, certainly we should have it written down somewhere.
overview and plugin-api reference 2.4 but there is no statement - we
should also advise our users more clearly.
https://bugs.edge.launchpad.net/bzr/+bug/597473

>>which on 2 is a no-op, and on 3 reencodes using latin-1 (so everything
>>works). Or we could split out separate files to import on 2 and 3, but
>>I think the extra seek would make it a wash perf wise.
>
> Or split it out for Python 2.4/2.6+ compatibility?  At least you can write
> idioms for the latter that 2to3 can more easily transform.  E.g...

I think if we're going for separate files, we'd want a real perf win,
because adding (say) 10% more files to bzrlib would suck, and user
strings (vs protocol definitions) are fairly mutable. That is, we
tweak a lot.

>>The no brainers (simple, not terribly ugly, not used a lot in our code):
>>octal 0666 ->0o666
>>print foo, bar -> print("%s %s" % (foo, bar))
>
> from __future__ import print_function
> print(foo, bar)

Its a little nicer, but for print statements this implies two copies
of the literal foo to update - see under maintenance burden.

>>exec foo, locals() -> exec(foo, locals())
>>
>>Somewhat ugly - we're going to see a lot of these:
>>except Foo, e:
>
> except Foo as e:

that is nicer, but two copies of the same code isn't. If we could hook
into the python compiler and just monkey patch it on 2.4->2.5, that
would be nice.

>>->
>>except Foo:
>>    e = sys.exc_info()[1]
>>
>>bytestrings:
>>This has the potential to slow load times slightly: in 3 to get a
>>bytestring one says b'foo', but you can't do that in 2, so for
>>single-source compatibility it gets written as:
>> _b('foo')
>
> b'foo' FTW. :)

Yes. For protocol stuff where this is relevant, we could split the
source - as above though, thats a pretty significant burden to wear.

>>
>>really ugly, but very few occurences:
>>    raise type, val, tb
>>->
>>    bzrlib.util.py._builtin._reraise(type, val, tb)
>
> raise

No, doesn't do what we need in any python version :)

We use 'raise', where we need to, but we also do reraise in a couple
of places, and switching it to raise there wouldn't work. Or we'd use
'raise' already :).

-Rob