[Python-Dev] Suggestion: new 3 release with backwards compatibility

[Ian Bicking]

On Tue, Jan 5, 2010 at 3:07 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>
> > It's not even that easy -- libraries can't apply patches for Python 3
> > compatibility as they usually break Python 2 compatibility.  Potentially
> > libraries could apply patches that make a codebase 2to3 ready, but from
> > what I've seen that's more black magic than straight forward updating,
> > as such patches have to trick 2to3 producing the output that is desired.
>
> I wouldn't qualify it in that way. It may be necessary occasionally to
> trick 2to3, but that's really a bug in 2to3 which you should report, so
> that trickery is then a work-around for a bug - something that you may
> have to do with other API, as well.
>
> The "black magic" is really more in the parts that 2to3 doesn't touch
> at all (because they are inherently not syntactic); these are the
> problem areas Guido refers to. The "black magic" then is to make the
> same code work unmodified for both 2.x and 3.x.

Just to clarify, the black magic I'm referring to is things like:

try:
    unicode_ = unicode
except NameError:
    unicode_ = str

and some other aliases like this that are unambiguous and which 2to3
won't touch (if you write them correctly).  If the porting guide noted
all these tricks (of which several have been developed, and I'm only
vaguely aware of a few) that would be helpful.  It's not a lot of
tricks, but the tricks are not obvious and 2to3 gets the translation
wrong pretty often without them.  For instance, when I say str in
Python 2 I often means bytes, unsurprisingly, but 2to3 translates both
str and unicode to str.  That *nothing* translates to bytes by default
(AFAIK) means that people must either be living in a bytes-free world
(which sure, lots of code does) or they are using tricks not included
in 2to3 itself.


Also replying to Glyph:
> > Also, running 2to3 on installation is kind of annoying, as you get source that isn't itself the canonical source, so to fix bugs you have to look at the installed source and trace it back to the bug in the original source.
>
> Given the way tracebacks are built, i.e. from filenames stored in .pycs rather than based on where the code was actually loaded in
the filesystem, couldn't 2to3 could do .pyc rewriting to point at the
original source?  Sort of like our own version of the #line directive?
:)
>
> Seriously though, I find it hard to believe that this is a big problem.  The 3.x source looks pretty similar to the 2.x source, and it's good to look at both if you're dealing with a 3.x issue.

Since 2to3 maintains line numbers yes, it wouldn't be that bad.  But
then I don't currently develop any code that is "installed", I only
develop code that is directly from a source code checkout, and where
the checkout is put on the path.  I guess I could have something that
automatically builds the code on every edit, and that's not
infeasible.  It's just not fun.  So long as I have to support Python 2
(which is like forever) then adding Python 3 only makes development
that much more complicated and much less fun, with no concrete
benefits.  Which is a terribly crotchety of me.  Sorry.

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker