On Tue, Jan 5, 2010 at 3:07 PM, "Martin v. Löwis" firstname.lastname@example.org 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.