guido@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