[Python-Dev] Suggestion: new 3 release with backwards compatibility
"Martin v. Löwis"
martin at v.loewis.de
Tue Jan 5 23:23:53 CET 2010
> Just to clarify, the black magic I'm referring to is things like:
> 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.
No, that's not what's happening. Instead, str is not translated at all
(i.e. it's *not* translated to str - it just isn't touched).
Translating unicode to str is always correct, AFAICT.
I'm not quite sure what the magic above is supposed to achieve: in 2.x,
unicode_ becomes an alias to unicode, in 3.x, 2to3 translates unicode
to str, and then the block becomes
unicode_ = str
unicode_ = str
so the NameError is actually never triggered.
Could it be that the magic is proposed for a mode where you *don't*
> 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.
By your above definition of "translates", the function "bytes" is
translated to bytes (i.e. it isn't touched by 2to3).
> 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.
Depends on where you draw your fun from. It is indeed fun to me, but
I can see why it may not be fun to you. So you could ask me to do it for
you - or you may try to use what I have already done for you, so you
don't have to do it.
> 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
I doubt it will be *much* more complicated - only a little.
As for concrete benefits: there may be no benefits at this point,
but in the long run, starting now will have saved you a lot of
pressure in the long run, and stop users from switching away from
your packages because of lack of Python 3 support.
More information about the Python-Dev