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