On Jan 9, 6:11 pm, John Machin <sjmac...@lexicon.net> wrote: > On Jan 10, 6:58 am, Carl Banks <pavlovevide...@gmail.com> wrote: > > > > > On Jan 9, 12:36 pm, "J. Cliff Dyer" <j...@sdf.lonestar.org> wrote: > > > > On Fri, 2009-01-09 at 13:13 -0500, Steve Holden wrote: > > > > Aivar Annamaa wrote: > > > > >> As was recently pointed out in a nearly identical thread, the -3 > > > > >> switch only points out problems that the 2to3 converter tool can't > > > > >> automatically fix. Changing print to print() on the other hand is > > > > >> easily fixed by 2to3. > > > > > >> Cheers, > > > > >> Chris > > > > > > I see. > > > > > So i gotta keep my own discipline with print() then :) > > > > > Only if you don't want to run your 2.x code through 2to3 before you use > > > > it as Python 3.x code. > > > > > regards > > > > Steve > > > > And mind you, if you follow that route, you are programming in a > > > mightily crippled language. > > > How do you figure? > > > I expect that it'd be a PITA in some cases to use the transitional > > dialect (like getting all your Us in place), but that doesn't mean the > > language is crippled. > > What is this "transitional dialect"? What does "getting all your Us in > place" mean?
Transitional dialect is the subset of Python 2.6 that can be translated to Python3 with 2to3 tool. Getting all your Us in place refers to prepending a u to strings to make them unicode objects, which is something 2to3 users are highly advised to do to keep hassles to a minimum. (Getting Bs in place would be a good idea too.) > Steve & Cliff are talking about the rather small subset of Python that > is not only valid syntax in both 2.x and 3.x but also has the same > meaning in 2.x and 3.x. That would be a crippled language, yes. But I do not believe that's what Steve and Cliff are referring to. Steve wrote of "running your code through 2to3", and that was what Cliff followed up to, so I believe they are both referring to writing valid code in 2.6 which is able to be translated through 2to3, and then generating 3.0 code using 2to3. That is not a crippled language at all, just a PITA sometimes. > > > It's about as bad as trying to write > > > cross-browser CSS. Don't put yourself through that pain if you don't > > > have to. > > > Have you tried doing that, or are you imagining how it will be? I'm > > curious about people's actual experiences. > > I maintain two packages, xlrd which supports 2.1 to 2.6, and xlwt > which supports 2.3 to 2.6. I've done suck-it-and-see trials on being > able to support 3.x as well from the same codebase, and it's turned > out reasonably well. xlrd already had a module called timemachine > which caters for version- dependent stuff. Extending this to 3.x was > more a voyage of discovery than a PITA. timemachine.py is "crippled" > in Cliff's sense, in that because I'm the principal user I need to > make it robust and idiot-proof, so it has been written under the > following constraints: > (1) not one copy of timemachine.py for 2.1, one for 2.2, one for > 2.3, ... etc; just one copy, period. > (2) means that it must use syntax that's valid in all supported > versions > (3) must be able to be processed by 2to3 without causing a commotion > (4) the original version and the 2to3 output must have the same effect > when imported by 3.x. > > So one ends up with code like: > glued = BYTES_NULL.join(list_of_pieces_of_a_binary_file) > which is supported by timemachine definitions like > BYTES_NULL = bytes(0) # 3.x ... note b'' is not valid in 2.x > BYTES_NULL = '' # 2.x > > BYTES_NULL.join() may be ugly, but it's not crippled, it's fully > functional, and it would be very easy to find and change in the future > in two possible scenarios (1) drop 2.x support (2) change codebase to > be mostly 3.x, support 2.x by a (mythical, hoped-for) 3to2 mechanism. Cool, thanks. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
