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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4