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

[Michael Foord]

On 13/12/2011 14:28, Laurence Rowe wrote:
> 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.

Ah, you mean a 2toPython3compatible2  converter. Not a bad idea.

Michael

>
> Laurence
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>


-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html