Python 3

[Robert Collins]

On Wed, Jun 23, 2010 at 11:52 AM, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
> Robert Collins <robertc at robertcollins.net> writes:
>
>> 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.
>
> Why not simply use Python 2's “u'foo'” syntax?

It is incompatible with the Python 3 parser.

robertc at lifeless-64:~$ python3.1
Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> u'\u1234'
  File "<stdin>", line 1
    u'\u1234'
            ^
SyntaxError: invalid syntax


This is the docstring from testtools.compat for its _u function (just
tidied up a few minutes ago):
+"""A function version of the 'u' prefix.
+
+This is needed becayse the u prefix is not usable in Python 3 but is required
+in Python 2 to get a unicode object.
+
+To migrate code that was written as u'\u1234' in Python 2 to 2+3 change
+it to be _u('\u1234'). The Python 3 interpreter will decode it
+appropriately and the no-op _u for Python 3 lets it through, in Python
+2 we then call unicode-escape in the _u function.
+"""


> This doesn't entail maintaining two separate code bases: rather the
> Python 2 code base is what gets maintained. A run of ‘2to3’ followed by
> the full test suite run under Python 3 can be an indicator of how ready
> the code base is for Python 3.

Modulo:
 - 2to3 limits and issues
 - users with unknown versions of 2to3
 - every distro out there

> (This doesn't cover C modules, but they're a separate headache either
> way.)

And bytestrings.

> Eventually, the decision is made to switch to Python 3. This is only
> done some time after the ‘2to3’-output passes the full test suite under
> Python 3.
>
> So why would this ‘_u()’ shim be necessary or desirable?

Because 2to3 is not complete, and structuring 'work with Python3' as a
cutover event - 'switch to 3 only when its ready' does not fit in with
the evolutionary approach we've taken to supporting Python 2.5, then
2.6, and 2.7 now.

Cutover transitions are harsh, slower than expected, dilute community
support, leave users behind unnecessarily.

-Rob