Problem with -3 switch

[John Machin]

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?

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