[Python-Dev] Improved super/autosuper

[Delaney, Timothy C (Timothy)]

guido at python.org wrote:

>> The current `super` implementation was always (as I understood it)
>> meant to be an interim solution until a better syntax could be
>> determined. 
> 
> Fair enough, although I doubt that I said it that way -- I believe I
> simply said something like "and here's how you can do 'super' using
> descriptors."

Hmm - thought I'd seen it in various conversations online (as opposed to
in the intro doc). Oh well ...

> I haven't downloaded that to test it thoroughly, and the code is way
> too hairy to understand easily, so I'm just asking here: how sure are
> you that it always does the right thing?  There are some seriously
> nasty edge cases for super, including making sure you always follow
> the MRO correctly.

Yeah - it's somewhat hairy at the moment. I'd like to simplify it
further (it's better than it was ...). I came across a number of edge
cases while implementing this that are dealt with.

I definitely can't claim that I'm 100% sure that it does the right thing
- haven't developed a full test suite for it yet (obviously) - this was
something I've done in a couple of hours of "spare time" in the last
couple of days. Mainly I wanted to get it out to the wider community to
see if it was worthwhile pursuing further - and for other people to pick
apart and criticise.

> Just as important is not having to hardcode the method (and you
> support that as well).  But that requires using sys._getframe() or
> other nastiness to find the method name.

Yeah - I meant to mention that (I did in the Cookbook). Yes, it uses
sys.getframe() :(

>> It's also backwards-compatible.
> 
> Sure, although I'm not sure I understand in what sense.  I guess you
> mean it doesn't define new keywords?

No new keywords, doesn't impinge on the existing use of super. If it's
implemented correctly (yet to be proven ;) existing uses of super and
this can be used side-by-side, even in the same method.

>> Would there be any interest in doing further work on this with the
>> aim of getting it into the core?
> 
> Hmm...  I'd rather work on a syntactic approach so the compiler can
> generate the appropriate call to the current super built-in.

That would be preferable. Although I do like having super be a property
on the instance - it makes method calls on super consistent with
everything else. I'd see this as a property on `object` in that case.

Initially I wasn't passing self, but just finding it from the stack
frame. I'd actually gone away from that approach though before I
remembered that wouldn't work with psyco anyway :)

>> BTW, I've made a couple of design choices which I'm not sure about.
>> Specifically, I've made `self.super` *not* throw an AttributeError
>> when no base class has the attribute - this simplifies dealing with
>> mixin classes (since you can just blindly put the self.super call
>> in). 
> 
> This is clearly wrong.  If your code doesn't even know whether there's
> a base class method or not, I doubt that you understand your base
> class well enough to be able to extend it.  Introducing a new method
> should be clearly different from overriding an existing one
> (conceptually)!

The more I think about it, the more it should be that the default should
be to throw exceptions. The rationale behind not throwing attribute
exceptions is primarily mix-in classes - they can't know where in the
MRO they're going to be - whether or not their attributes are going to
interfere with other classes in the MRO. However, the more I think about
it, the less examples I can think of where it would be a good thing to
do.

>> I've included a second property `super_raise` for when you want the
>> exception. Most of my usage works better without the exception
>> (since everything resolves back to object, and it doesn't have many
>> methods ...). But I'd like other people's opinion on which is
>> preferable.
> 
> You've got mine. :-)

OK - super raises. super_raise goes away, and there is no equivalent for
not raising. If people want that, they can subclass :)

Thanks for the comments Guido. I think I'll let it soak for a while and
see what other people think about it.

Tim Delaney