Problem with -3 switch

[Carl Banks]

On Jan 9, 6:11 pm, John Machin <sjmac... at lexicon.net> wrote:
> On Jan 10, 6:58 am, Carl Banks <pavlovevide... at gmail.com> wrote:
>
>
>
> > On Jan 9, 12:36 pm, "J. Cliff Dyer" <j... at 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