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

["Martin v. Löwis"]

> 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.

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

try:
  unicode_ = str
except NameError:
  unicode_ = str

so the NameError is actually never triggered.

Could it be that the magic is proposed for a mode where you *don't*
use 2to3?

> 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
> benefits.

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.

Regards,
Martin