Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6773 > unrolled thread

Updated blog post on how to use super()

Back to article view | Back to comp.lang.python

Contents

  Updated blog post on how to use super() Raymond Hettinger <python@rcn.com> - 2011-05-31 19:44 -0700
    Re: Updated blog post on how to use super() Ben Finney <ben+python@benfinney.id.au> - 2011-06-01 14:26 +1000
    Re: Updated blog post on how to use super() Billy Mays <noway@nohow.com> - 2011-06-01 09:03 -0400
      Re: Updated blog post on how to use super() Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-01 10:42 -0600
        Re: Updated blog post on how to use super() Billy Mays <noway@nohow.com> - 2011-06-01 12:46 -0400
          Re: Updated blog post on how to use super() Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-01 11:06 -0600
          Re: Updated blog post on how to use super() Chris Torek <nospam@torek.net> - 2011-06-01 17:43 +0000
      Re: Updated blog post on how to use super() Duncan Booth <duncan.booth@invalid.invalid> - 2011-06-02 20:58 +0000

#6773 — Updated blog post on how to use super()

I've tightened the wording a bit, made much better use of keyword
arguments instead of kwds.pop(arg), and added a section on defensive
programming (protecting a subclass from inadvertently missing an MRO
requirement).  Also, there is an entry on how to use assertions to
validate search order requirements and make them explicit.

  http://bit.ly/py_super
     or
  http://rhettinger.wordpress.com/2011/05/26/super-considered-super/

Any further suggestions are welcome.  I'm expecting this to evolve
into how-to guide to be included in the regular Python standard
documentation.  The goal is to serve as a reliable guide to using
super and how to design cooperative classes in a way that lets
subclasses compose and extent them.


Raymond Hettinger

--------
follow my python tips on twitter: @raymondh

[toc] | [next] | [standalone]

#6785

Raymond Hettinger <python@rcn.com> writes:

> Any further suggestions are welcome.

I am impressed by your optimistic outlook:

    For reorderable method calls to work, the classes need to be
    designed cooperatively. This presents three easily solved practical
    issues[…]

:-)

It's a good document, and I'm very glad this effort is being made to
provide guidance on this feature.

-- 
 \      “The trouble with the rat race is that even if you win, you're |
  `\                       still a rat.” —Jane Wagner, via Lily Tomlin |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#6791

On 5/31/2011 10:44 PM, Raymond Hettinger wrote:
> I've tightened the wording a bit, made much better use of keyword
> arguments instead of kwds.pop(arg), and added a section on defensive
> programming (protecting a subclass from inadvertently missing an MRO
> requirement).  Also, there is an entry on how to use assertions to
> validate search order requirements and make them explicit.
>
>    http://bit.ly/py_super
>       or
>    http://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>
> Any further suggestions are welcome.  I'm expecting this to evolve
> into how-to guide to be included in the regular Python standard
> documentation.  The goal is to serve as a reliable guide to using
> super and how to design cooperative classes in a way that lets
> subclasses compose and extent them.
>
>
> Raymond Hettinger
>
> --------
> follow my python tips on twitter: @raymondh

I read this when it was on HN the other day, but I still don't see what 
is special about super().  It seems (from your post) to just be a stand 
in for the super class name?  Is there something special I missed?

--
Bill

[toc] | [prev] | [next] | [standalone]

#6799

On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays <noway@nohow.com> wrote:
> I read this when it was on HN the other day, but I still don't see what is
> special about super().  It seems (from your post) to just be a stand in for
> the super class name?  Is there something special I missed?

It's not a stand-in for the super-class name.  It's a stand-in for
whatever class is next in the Method Resolution Order (MRO), which is
determined at run-time and can vary depending on what the actual class
of the object is.  For example, in this inheritance situation:

class A(object):
    ...

class B(object):
    ...

class C(A, B):
    ...

a = A()
c = C()

The MRO of A is (A, object).
The MRO of B is (B, object).
The MRO of C is (C, A, B, object).

Thus, super(A, a) is going to resolve to object, as you might expect.
But super(A, c) is going to resolve to B, because the next class after
A in the MRO for C instances is B.

That's a pretty quick and dirty explanation.  If it doesn't make
sense, I suggest reading the article again.

[toc] | [prev] | [next] | [standalone]

#6800

On 6/1/2011 12:42 PM, Ian Kelly wrote:
> On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays<noway@nohow.com>  wrote:
>> I read this when it was on HN the other day, but I still don't see what is
>> special about super().  It seems (from your post) to just be a stand in for
>> the super class name?  Is there something special I missed?
>
> It's not a stand-in for the super-class name.  It's a stand-in for
> whatever class is next in the Method Resolution Order (MRO), which is
> determined at run-time and can vary depending on what the actual class
> of the object is.  For example, in this inheritance situation:
>
> class A(object):
>      ...
>
> class B(object):
>      ...
>
> class C(A, B):
>      ...
>
> a = A()
> c = C()
>
> The MRO of A is (A, object).
> The MRO of B is (B, object).
> The MRO of C is (C, A, B, object).
>
> Thus, super(A, a) is going to resolve to object, as you might expect.
> But super(A, c) is going to resolve to B, because the next class after
> A in the MRO for C instances is B.
>
> That's a pretty quick and dirty explanation.  If it doesn't make
> sense, I suggest reading the article again.

What it does is clear to me, but why is it interesting or special isn't. 
  This looks like a small feature that would be useful in a handful of 
cases.

--
Bill

[toc] | [prev] | [next] | [standalone]

#6804

On Wed, Jun 1, 2011 at 10:46 AM, Billy Mays <noway@nohow.com> wrote:
> What it does is clear to me, but why is it interesting or special isn't.
>  This looks like a small feature that would be useful in a handful of cases.

Well, I agree with you there.  The complexity introduced by super
typically outweighs the benefits it provides, IMO.  The only time when
it is really necessary is in non-trivial diamond inheritance
situations (to avoid calling the same method on some base class more
than once), and in those cases I think it is simply better to not use
multiple inheritance in the first place.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#6810

Summary: super(cls, data) in a method gets you the "next" handler
for a given class "cls" and an instance "data" that has derived
from that class at some point.  In Python 2 you must spell out the
names of the class and instance (normally "self") explicitly, while
Python 3 grabs, at compile time, the class from the lexically
enclosing class, and the instance from the first argument of the
method that invokes "super".

The "next" handler depends on the instance's __mro__.  If all
your classes use at most single inheritance, the "next" handler
in class Cls1 is easy to predict:

    class Cls1(Cls2):

Any instance of Cls1 always has Cls2 as its "next", so:

        def method(self, arg1, arg2):
            ...
            Cls2.method(self, arg1_mutated, arg2_mutated)
            ...

works fine.  But if you use multiple inheritance, the next method
is much harder to predict.  If you have a working "super", you
can use:

            super().method(self, arg1_mutated, arg2_mutated)

and it will find the correct "next method" in all cases.

In article <is5qd7$t5b$1@speranza.aioe.org>
Billy Mays  <noway@nohow.com> wrote:
>What it does is clear to me, but why is it interesting or special isn't. 
>  This looks like a small feature that would be useful in a handful of 
>cases.

Indeed: it is useful when you have multiple inheritance, which for
most programmers, is a "handful of cases".

However, provided you *have* the Py3k super() in the first place,
it is also trivial and obviously-correct to write:

        super().method(...)

whereas writing:

        NextClass.method(...)

requires going up to the class definition to make sure that
"NextClass" is indeed the next class, and hence -- while usually
no more difficult to write -- less obviously-correct.

Moreover, if you write the easy-to-write obviously-correct
"super().method", *your* class may now be ready for someone
else to use in a multiple-inheritance (MI) situation.  If you type
in the not-as-obviously-correct "NextClass.method", *your* class
is definitely *not* ready for someone else to use in that MI
situation.

(I say "may" be ready for MI, because being "fully MI ready" requires
several other code discipline steps.  The point of super() -- at
least when implemented nicely, as in Py3k -- is that it makes it
easy -- one might even say "super easy" :-) -- to write your code
such that it is obviously correct, and also MI-friendly.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html

[toc] | [prev] | [next] | [standalone]

#6886

Billy Mays <noway@nohow.com> wrote:

> I read this when it was on HN the other day, but I still don't see what 
> is special about super().  It seems (from your post) to just be a stand 
> in for the super class name?  Is there something special I missed?
> 
Consider any diamond hierarchy:

class Base(object): pass
class A(Base): pass
class B(Base): pass
class C(A, B): pass

If you have an instance of C, then in a method in A super() could refer to 
a method in B which is not a base class of A.

If you have an instance of A then the sampe super() reference in one of A's 
methods refers to the method in Base.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web