[Python-Dev] readd u'' literal support in 3.3? (original) (raw)

Laurence Rowe l at lrowe.co.uk
Tue Dec 13 15:28:31 CET 2011

On Tue, 13 Dec 2011 14:42:12 +0100, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:

On 13/12/2011 13:33, Laurence Rowe wrote:

On Mon, 12 Dec 2011 22🔞40 +0100, Chris McDonough <chrism at plope.com> wrote:

On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:

As someone who ported WebOb and other stuff built on top of it to Python 3 without using "from future import unicodeliterals", I'm kinda sad that to be using best practice I'll have to go back and flip the polarity on everything.

Eh? If you don't need unicodeliterals, what's the problem? Porting the WebOb code sucked. It's only about 5K lines of code but the porting effort took me about 80 hours. Some of the problem is certainly my own idiocy, but some of it is just because straddling code across Python 2 and Python 3 currently requires that you change lots and lots of code for suspect benefit. Could this manual work be cut down if there was a version of 2to3 that targeted the subset of the language that is compatible with both 2 and 3? That would seem to avoid most of the drawbacks to the current 2to3 approach. I'm not sure what you mean, but it reads as if you mean "a version of 2to3 that only converts code that doesn't need converting". Could you clarify?

The approach that most people seem to have settled on for porting
libraries to Python 3 is to make a single codebase that is compatible with
both Python 2 and Python 3, perhaps making use of the six library. If I
understand correctly, Chris' experience of porting WebOb was that there is
a large amount of manual work required in this approach in part because of
the many u'' strings in libraries that extensively use unicode. It should
be possible to automate this with the same approach as 2to3, but instead
of a transform from 2->3 it would transform code from 2->(2 & 3). In this
case the transform would only have to be run once (rather than on every
setup.py install) and would avoid the difficulties of debugging with
tracebacks that do not exactly match the source code.

Laurence

More information about the Python-Dev mailing list