[Python-Dev] Problems with the new super()

[Guido van Rossum]

On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <g.brandl at gmx.net> 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" [1]. 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.

>  cheers,
>  Georg
>
>  [1] 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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)