[Python-Dev] Improved super/autosuper

Guido van Rossum guido at python.org
Tue Jul 6 06:24:09 CEST 2004


> 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."

> I've submitted a recipe to the Cookbook for an improved super/autosuper
> which allows using syntax like:
> 
>     class A (autosuper):
> 
>         def __init__ (self, a, b):
>             print 'A.__init__'
>             print a, b
>             self.super(a, b)
> 
>         def test (self, a, b):
>             print 'A.test'
>             print a, b
>             self.super(a, b)
> 
>     class B (A):
> 
>         def __init__ (self):
>             print 'B.__init__'
>             self.super(1, 2)
>             self.super.test(3, 4)
> 
>     B()
> 
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286195

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.

> It's currently got some fairly serious inefficiencies in it, but it
> shows that it is viable to produce a simpler `super` that doesn't
> require hardcoding the class.

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.

> 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?

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

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

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

--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list