Python 3

[Robert Collins]

I've done a couple of trivial patches moving in the direction of being
able to play with Python 3 and bzr.

I'd like to document some changes to our coding style, to make
eventual Python 3 migration easier - but they aren't all no-brainers
so I thought I'd raise stuff here and we can discuss it.

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))
exec foo, locals() -> exec(foo, locals())

Somewhat ugly - we're going to see a lot of these:
except Foo, e:
->
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')

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.

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

Now, there are a lot of other things that we will have to solve and
talk about, this is really top level mechanical stuff and should not
be taken as the whole list or a magic bullet.

However, I think changing our coding style this and not much more will
be enough to let interested people slowly push forward and get things
like:
 - the test suite
 - C / pyrex modules
and so forth working on 3.

I think that ideally, in a year or so we'd be in a position to make a
concerted push to make 3 a first class citizen (because 3 is getting
considerable upstream and in-distribution attention).

If the consensus from this thread is that this is ok, I'll update
HACKING docs appropriately.

-Rob