Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword

Guido van Rossum wrote:
Yep - I've just used a placeholder name.
Also, this would have to be done when the class is defined; when the method is being defined the class doesn't exist yet.
Good point. Change that to "at the first opportunity" ;)
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()
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.
http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exam ples
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 ... Tim Delaney

Delaney, Timothy (Tim) wrote:
As Guido pointed out it has some resemblance to how import works, but I also think there is resemblance to the context of how global is used. So if it is made into a keyword, could it work like the global keyword? class A(object): def f(self): def inner(): super f return 'A' + f() print inner() Cheers, Ron

From: "Delaney, Timothy (Tim)" <tdelaney@avaya.com>
A 'super' instance would be callable, without being able to access it's __call__ method (because super.__call__ would refer to the base class method of that name). But I find I really don't care. The only place where that would really matter IMO is if you want to find out if a 'super' instance is callable. Calling a base class __call__ method would not be ambiguous - the following two classes would work the same: class A(object): def __call__(self, *p, **kw): return super.__call__(*p, **kw) class A(object): def __call__(self, *p, **kw): return super(*p, **kw) So, I guess my question is whether the most common case of calling the base class method with the same name is worth having some further syntactic sugar to avoid repetition? I think it is, but that would be your call Guido. Cheers, Tim Delaney

On 4/30/07, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:
I believe the direction my PEP took with all this is a good bit primitive compared to this approach, although I still find value in it because at least a prototype came out of it that can be used to test the waters, regardless of if a more direct-in-the-language approach would be superior. However, I seem to think that if the __this_class__ PEP goes through, your version can be simplified as well. No tricky stuffy things in cells would be needed, but we can just expand the super 'keyword' to __super__(__this_class__, self), which has been suggested at least once. It seems this would be much simpler to implement, and it also brings up a second point. Also, I like that the super object is created at the beginning of the function, which my proposal couldn't even do. It is more efficient if you have multiple super calls, and gets around a problem I completely missed: what happens if the instance name were rebound before the implicit lookup of the instance object at the time of the super call?
Turns out, it doesn't. A lot of people expect it, but it turns out to be simple. super(*p, **kw) is not equivalent to super.__call__(*p, **kw) but to type(super).__call__.__get__(super, type(super))(*p, **kw), due to operator methods being looked up on the type directly and bound by the descriptor, without any lookup on the super object itself. Thus, no attribute is ever done on the super object itself, type(super).__getattribute__ is never invoked, and there is no problem at all. This also means we can still invoke super the old, explicit way. I've already got my copy of the PEP updated to reflect this.
Does super mean anything in a static method today? -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/

From: "Calvin Spealman" <ironfroggy@gmail.com>
I've been working on improved super syntax for quite a while now - my original approach was 'self.super' which used _getframe() and mro crawling too. I hit on using bytecode hacking to instantiate a super object at the start of the method to gain performance, which required storing the class in co_consts, etc. It turns out that using a metaclass then makes this a lot cleaner.
You could expand it inline, but I think your second point is a strong argument against it. Also, sticking the super instance into a cell means that inner classes get access to it for free. Otherwise each inner class would *also* need to instantiate a super instance, and __this_class__ (or whatever it's called) would need to be in a cell for them to get access to it instead. BTW, one of my test cases involves multiple super calls in the same method - there is a *very* large performance improvement by instantiating it once.
Well, since all super instantiations are explicit currently, it can mean whatever you want it to. class A(object): @staticmethod def f(): print super(A) print super(A, A) Cheers, Tim Delaney

On 4/30/07, Tim Delaney <tcdelaney@optusnet.com.au> wrote:
Note that I would now advocate the creation of the super object at the beginning of function, and when I talk about expanding super to super(__this_class__, self) I do mean doing it at the beginning of the function, just like you are saying, so we're in agreement here. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/

Tim Delaney wrote:
And how does speed deteriorate for methods with no uses of super at all (which will, I suspect, be in the majority)? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------

On 4/29/07, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:
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.
I think the shortcut is more confusing than helpful; I propose to drop it for the sake of focusing on the essential.
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/)

Delaney, Timothy (Tim) wrote:
As Guido pointed out it has some resemblance to how import works, but I also think there is resemblance to the context of how global is used. So if it is made into a keyword, could it work like the global keyword? class A(object): def f(self): def inner(): super f return 'A' + f() print inner() Cheers, Ron

From: "Delaney, Timothy (Tim)" <tdelaney@avaya.com>
A 'super' instance would be callable, without being able to access it's __call__ method (because super.__call__ would refer to the base class method of that name). But I find I really don't care. The only place where that would really matter IMO is if you want to find out if a 'super' instance is callable. Calling a base class __call__ method would not be ambiguous - the following two classes would work the same: class A(object): def __call__(self, *p, **kw): return super.__call__(*p, **kw) class A(object): def __call__(self, *p, **kw): return super(*p, **kw) So, I guess my question is whether the most common case of calling the base class method with the same name is worth having some further syntactic sugar to avoid repetition? I think it is, but that would be your call Guido. Cheers, Tim Delaney

On 4/30/07, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:
I believe the direction my PEP took with all this is a good bit primitive compared to this approach, although I still find value in it because at least a prototype came out of it that can be used to test the waters, regardless of if a more direct-in-the-language approach would be superior. However, I seem to think that if the __this_class__ PEP goes through, your version can be simplified as well. No tricky stuffy things in cells would be needed, but we can just expand the super 'keyword' to __super__(__this_class__, self), which has been suggested at least once. It seems this would be much simpler to implement, and it also brings up a second point. Also, I like that the super object is created at the beginning of the function, which my proposal couldn't even do. It is more efficient if you have multiple super calls, and gets around a problem I completely missed: what happens if the instance name were rebound before the implicit lookup of the instance object at the time of the super call?
Turns out, it doesn't. A lot of people expect it, but it turns out to be simple. super(*p, **kw) is not equivalent to super.__call__(*p, **kw) but to type(super).__call__.__get__(super, type(super))(*p, **kw), due to operator methods being looked up on the type directly and bound by the descriptor, without any lookup on the super object itself. Thus, no attribute is ever done on the super object itself, type(super).__getattribute__ is never invoked, and there is no problem at all. This also means we can still invoke super the old, explicit way. I've already got my copy of the PEP updated to reflect this.
Does super mean anything in a static method today? -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/

From: "Calvin Spealman" <ironfroggy@gmail.com>
I've been working on improved super syntax for quite a while now - my original approach was 'self.super' which used _getframe() and mro crawling too. I hit on using bytecode hacking to instantiate a super object at the start of the method to gain performance, which required storing the class in co_consts, etc. It turns out that using a metaclass then makes this a lot cleaner.
You could expand it inline, but I think your second point is a strong argument against it. Also, sticking the super instance into a cell means that inner classes get access to it for free. Otherwise each inner class would *also* need to instantiate a super instance, and __this_class__ (or whatever it's called) would need to be in a cell for them to get access to it instead. BTW, one of my test cases involves multiple super calls in the same method - there is a *very* large performance improvement by instantiating it once.
Well, since all super instantiations are explicit currently, it can mean whatever you want it to. class A(object): @staticmethod def f(): print super(A) print super(A, A) Cheers, Tim Delaney

On 4/30/07, Tim Delaney <tcdelaney@optusnet.com.au> wrote:
Note that I would now advocate the creation of the super object at the beginning of function, and when I talk about expanding super to super(__this_class__, self) I do mean doing it at the beginning of the function, just like you are saying, so we're in agreement here. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/

Tim Delaney wrote:
And how does speed deteriorate for methods with no uses of super at all (which will, I suspect, be in the majority)? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------

On 4/29/07, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:
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.
I think the shortcut is more confusing than helpful; I propose to drop it for the sake of focusing on the essential.
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/)
participants (6)
-
Calvin Spealman
-
Delaney, Timothy (Tim)
-
Guido van Rossum
-
Ron Adam
-
Steve Holden
-
Tim Delaney