This is a pretty good overview of some key deficiencies. I wish he would have left the "not backwards compatible" complaints out -- backwards compatibility is a well-known non-goal, and it's a non-issue how difficult (or subtle) porting code to Py3 from Py2 is.
The super() stuff is unfortunate. It seems that Py3 manages to clean up so very many other uglinesses of the language... to see a new, obviously ugly thing introduced...
Could you (or anyone else) elaborate on the issues with super() as described in this article? I'm having a hard time understanding what's going on between the complex details of the problem and the author's cumbersome syntactic choices.
The super() is magical. Functions aren't supposed to magically know what class or instance they are in unless they are explicitly passed on in Python. That's why you see the "self" argument in methods.
And in the 2nd example, he shows that if you copy super to another name, then it doesn't work. Presumably meaning that super which looks like a function, actually acts like a compiler keyword in certain cases.
Are his super() complaints really a problem in practice? I for one have always disliked the non-DRYness of typing "super(C, self).method(arg)", and Python 3's super() really improves on that for real-world cases.
I haven't done much Unicode string transformation, so can't comment much there. But why can't Python 3's str.lower() or .upper() replace one letter with two? As for the locale thing, could it be solved by the str.lower() and .upper() functions taking an optional locale parameter? As for internal encoding, I'm guessing they'll switch to all-UCS4 over time.
I really like all of the changes they're making in Python 3. Though I admit I haven't switched yet -- waiting for the 3rd-party support to catch up. Looks like it's happening though.
The super() stuff is unfortunate. It seems that Py3 manages to clean up so very many other uglinesses of the language... to see a new, obviously ugly thing introduced...