[Python-3000] Fixing super anyone?

[Thomas Wouters]

On 4/19/07, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> On 4/18/07, Guido van Rossum <guido at python.org> wrote:
> > Is anyone available to write up a PEP on how to turn super into a
> > keyword? Inside regular and class methods, super.foo(args) should be
> > equivalent to super(ThisClass, self).foo(args). I think there are ways
> > to make the old syntax work too, but maybe that's only necessary for
> > 2.6.
>
> Does this mean it should find the super of the current class (which
> isn't yet defined when the method is being defined)?
>
> That would be a slight change (though probably an improvement) against
> today's lookup-by-name.
>
> If that change is OK, and no one else volunteers, I'll try to take a
> go at it this weekend.


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:

 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 ;)

 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.

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.

(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.)

There's also the question of what the super keyword itself should look like,
e.g.

  # declaration-style, no dot
  res = super currentmethod(arg, arg)
  # treat super like self
  res = super.currentmethod(arg, arg)
  # treat super like self.currentmethod
  res = super(arg, arg)

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__'.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070420/f3dd83c8/attachment.html