Python 3

[Jelmer Vernooij]

On Wed, 2010-06-23 at 09:47 +1200, Robert Collins wrote:
> 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.
Is supporting the two versions (that are quite different, at least where
Bazaar is concerned) from the same code base really a good idea ? 

I'm wondering if having a separate "python 3" branch of Bazaar to which
newer revisions are explicitly ported is perhaps less of a strain on
development than having to fix up portability issues in the main branch
all the time and by introducing various wrappers around standard
functions.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100623/fff01ddc/attachment.pgp