On 4/29/07, Delaney, Timothy (Tim) <tdelaney@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 co_cellvars. Given the following class:
class A(object): def f(self): super = super_factory()
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.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm proposing is that the `super = super_factory()` 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__(<class>, <firstarg>) 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/#metaclass_exampple... .
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/)