Grups de Google ja no admet publicacions ni subscripcions noves de Usenet. El contingut antic es pot continuar consultant.

Updated blog post on how to use super()

33 visualitzacions
Ves al primer missatge no llegit

Raymond Hettinger

no llegida,
31 de maig 2011, 22:44:0731/5/11
a
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

Ben Finney

no llegida,
1 de juny 2011, 0:26:441/6/11
a
Raymond Hettinger <pyt...@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

Billy Mays

no llegida,
1 de juny 2011, 9:03:421/6/11
a

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

Ian Kelly

no llegida,
1 de juny 2011, 12:42:061/6/11
a pytho...@python.org
On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays <no...@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.

Billy Mays

no llegida,
1 de juny 2011, 12:46:321/6/11
a

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

Ian Kelly

no llegida,
1 de juny 2011, 13:06:021/6/11
a Python
On Wed, Jun 1, 2011 at 10:46 AM, Billy Mays <no...@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

Chris Torek

no llegida,
1 de juny 2011, 13:43:191/6/11
a
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 <no...@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

Duncan Booth

no llegida,
2 de juny 2011, 16:58:272/6/11
a
Billy Mays <no...@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

0 missatges nous