On 4/29/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> 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_exampples > > . > > > > 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com