Python 3

[Robert Collins]

On Wed, Jun 23, 2010 at 10:50 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> ...
>
>> 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).
>
> Would you really be trying to do it by making the source code dual
> compatible, rather than using either something like 2to3, or by
> converting and using something like 3to2?

There are a bunch of ways we could do it. We haven't chosen one as a
project - and I think thats fine. Python3 is over the horizon for us.

However, there is interest in it now from various places, and that has
been growing over the last couple of years.

As I see it we have 2 major issues to address, which 2to3 and a 3to2
totally bail on.

Ignore syntax, syntax is easy and largely irrelevant - its noise.

C extensions are going to need an overhaul. We're going to want to
keep fixing two versions for a while; ifdefs and macros and pyrex are
good tools here; python2to3 doesn't help *at all*. See
http://docs.python.org/py3k/howto/cporting.html#cporting-howto

Secondly, we have the *huge*, appallingly huge, mess that is 'all
strings are unicode' in Python3. I expect a majority of the work is
going to be identifying which are which, annotating them appropriately
and dealing with the fallout of things like listdir eliding damaged
filenames (for some versions of 3.x). We may need to set a minimum
version of 3 to use - though I don't claim to have any idea here :).
Adding a _u() decorator - like Benjamins patch in testtools - to make
that explicit would be a fine step, and one that slipped my mind at
the start of this thread. (Such a decorator is a no-op on 3, like _b()
is on 2).

-Rob