[Python-Dev] readd u'' literal support in 3.3?

[Laurence Rowe]

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:18: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 unicode_literals", 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 unicode_literals, 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