[Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword (original) (raw)

Guido van Rossum guido at python.org
Mon Apr 30 19:43:18 CEST 2007

On 4/29/07, Delaney, Timothy (Tim) <tdelaney at avaya.com> wrote:

Guido van Rossum wrote: >> 2. Every non-static method has an implicit cell variable called >> 'super'. > > I think you're using 'cell' in a different sense than it is normally > used in Python's implementation. What you are looking for is called a > local variable (I deduce this from your initialization of the "cell" > with something computed from the first argument).

Actually, I think I'm using the terminology correctly - I'm talking about an entry in cocellvars. Given the following class: class A(object): def f(self): super = superfactory() def inner(): return 'A' + super.f() print inner() the use of 'super' in both A.f and A.f.inner will produce an entry in A.f.funccode.cocellvars and A.f.inner.funccode.cofreevars. What I'm proposing is that the super = superfactory() line be implicit in this case, resulting in the following code behaving identically: class A(object): def f(self): def inner(): return 'A' + super.f() print inner()

OK, I see now. I thought you meant for the cell-ness to be related to the basic implementation; but you meant it so that it woks correctly inside nested functions. That's fine of course. You might clarify this somewhere.

>> The issue of super() vs. super.call() ambiguity - I'll need to >> look at that when I get home. > > Sounds irrelevant -- if super is equivalent to > builtin.super(, ) then super never gets > called; the only thing ever done to it (in the normal course of > things) is to request an attribute of it.

Sorry - this is related to my proposal that the following two bits of code behave the same: class A(object): def f(self, *p, **kw): super.f(*p, **kw) class A(object): def f(self, *p, **kw): super(*p, **kw) But as has been pointed out, this creates an ambiguity with: class A(object): def f(self, *p, **kw): super.call(*p, **kw) so I want to see if I can resolve it.

I think the shortcut is more confusing than helpful; I propose to drop it for the sake of focusing on the essential.

> super(ThisClass).method(...) # ??? > > The third exists so that you can create an "unbound" super instance > which is useful for the oft-misunderstood autosuper example in my > "descrintro" essay: > > http://www.python.org/download/releases/2.2.3/descrintro/#metaclassexampples > . > > But since the latter is the hack that we're trying to replace with a > proper implementation here, I suspect we can get away with only > supporting the first two forms (and the third form is still supported > using builtin.super).

Yep - that's my thought as well. I think it would be very rare to need super(ThisClass), although it makes some sense that that would be what super means in a static method ...

But that doesn't work with the current (2.x) super, and hasn't been requested AFAIK, so I'd suggest dropping the use case -- KISS again.

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

More information about the Python-Dev mailing list