> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
