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? 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. > > > 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. > Problem is, a lot of people use the "bang at it with a hammer till it > works" approach to programming, and really have no shame when it comes > to engaging in questionable practices like relying on accidental side > effects, rather than taking the time to try to program robustly. I > expect people with that style of programming will have many more > issues with the transition. Those with many more issues are likely to be those who don't have adequate tests and/or can't debug their way out of a wet paper bag -- could well be we're talking about the same bunch :-) Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
