On Thu, May 1, 2008 at 11:20 AM, Georg Brandl email@example.com wrote:
But the other two magical things about super() really bother me too. I haven't looked at the new super in detail so far (and I don't know how many others have), and two things are really strikingly unpythonic in my view:
- super() only works when named "super" . It shouldn't be a function if
it has that property; no other Python function has that.
Actually, I believe IronPython and/or Jython have to use this trick in certain cases -- at least I recall Jim Hugunin talking about generating different code when the use of locals() was detected.
I'm not proud of this, but I don't see a way around it. The alternative would be to make it a keyword, which seemed excessive (plus, it would be odd if super() were a keyword when self is not). There were long discussions about various possible ways to implement something like this, and they all had their downsides. (The PEP still isn't fixed to describe the status quo.)
- "__class__" is magical in classes. If you define a local called
"__class__" super won't work anymore in that function.
Also, you can access "__class__" from any method, without the "self." qualifier -- another magical name.
I don't mind this at all -- it's a name starting and ending with double underscores, so you shouldn't use it except for its defined semantics, which happen to be exactly what super needs. (I would have proposed __super__() to get an exception for that too, except that it's excessively ugly.)
There may be more implications and surprising behavior surrounding this.
I know that the implementation is a compromise, but I'd rather see a super() whose full semantics can be explained to programmers without using to "cell variable", "f_localsplus" and "symtable".
You don't have to explain it that way at all. First you explain how the 2.x super(C, self) works. Then you explain that if you call it with no arguments, the arguments default to the current class object and the first argument of the current function. Only people wanting to write their own interpreter need to know more.
 Actually, it only works if a name "super" is accessed somewhere in the function, but this is what someone trying to alias "super" will perceive.
To Facundo, who asks if we need super() at all: yes, we need it. You can't write decent multiple-inheritance code without it.