<br><div><span class="gmail_quote">On 4/19/07, <b class="gmail_sendername">Jim Jewett</b> <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 4/18/07, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>> Is anyone available to write up a PEP on how to turn super into a<br>> keyword? Inside regular and class methods,
super.foo(args) should be<br>> equivalent to super(ThisClass, self).foo(args). I think there are ways<br>> to make the old syntax work too, but maybe that's only necessary for<br>> 2.6.<br><br>Does this mean it should find the super of the current class (which
<br>isn't yet defined when the method is being defined)?<br><br>That would be a slight change (though probably an improvement) against<br>today's lookup-by-name.<br><br>If that change is OK, and no one else volunteers, I'll try to take a
<br>go at it this weekend.</blockquote><div><br>I've had this near the top of my (Python) TODO list for a while, but I haven't been able to find the time. I've considered it while doing the dishes and such, though. I can think of two ways of doing the underlying magic "properly", and one way that's too ugly to think about:
<br><br> 1) Add a new type of descriptor-hook, for associating an object with the class it is an attribute of. After class creation (in the metaclass __init__), any object with this __associate__ (or whatever) hook gets it called. It's only called for objects that are attributes of *that* class, not of any superclasses (since they will already be associated with the superclass.) I'm sure there are other uses for this hook, just not methods that want to use super() -- like zope interfaces ;)
<br><br> 2) Add a new argument to __get__ (or a new method that acts like __get__ but with the extra argument, and is called instead of __get__ if it is defined) where the extra argument is the class that the retrieved descriptor is actually an attribute of. It currently (correctly) gets the class the attribute was retrieved through, which could be a subclass.
<br><br>In both these cases, the (un)bound method object would end up with knowledge of the class it is defined in, and create a local variable with a super-object for the 'super' keyword to use. There still are some grey areas to solve -- what if classes share functions, what if functions share code-objects, etc. #2 is probably a better way to go about it than #1, in that regard.
<br><br></div>(and 3) the fugly method: don't do anything special with methods, but have super() search through __mro__ for the first class to have the current function as an attribute, then pick the next class from that. Yecch, and more grey areas than the other two methods.)
<br></div><br>There's also the question of what the super keyword itself should look like, e.g.<br><br> # declaration-style, no dot<br> res = super currentmethod(arg, arg) <br> # treat super like self<br> res = super.currentmethod
(arg, arg)<br> # treat super like self.currentmethod <br clear="all"> res = super(arg, arg)<br><br>I think super.currentmethod(arg, arg) makes the most sense, but that may be because it most closely resembles the current practice. However, it may call the "wrong" supermethod when the class does, for instance, '__repr__ = __str__'.
<br> <br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!