Pyhton's super() considered super!

If you aren’t wowed by Python’s super() builtin, chances are you don’t really know what it is capable of doing or how to use it effectively.

Much has been written about super() and much of that writing has been a failure. This article seeks to improve on the situation by:

• providing practical use cases

• giving a clear mental model of how it works

• showing the tradecraft for getting it to work every time

• concrete advice for building classes that use super()

• favoring real examples over abstract ABCD?diamond diagrams.

The examples for this post are available in both?Python 2 syntax?and?Python 3 syntax.

Using Python 3 syntax, let’s start with a basic use case, a subclass for extending a method from one of the builtin classes:

This class has all the same capabilities as its parent,?dict, but it extends the __setitem__ method to make log entries whenever a key is updated. After making a log entry, the method uses super() to delegate the work for actually updating the dictionary with the key/value pair.

Before super() was introduced, we would have hardwired the call with?dict.__setitem__(self, key, value). However, super() is better because it is a computed indirect reference.

One benefit of indirection is that we don’t have to specify the delegate class by name. If you edit the source code to switch the base class to some other mapping, the super() reference will automatically follow. You have a single source of truth:

In addition to isolating changes, there is another major benefit to computed indirection, one that may not be familiar to people coming from static languages. Since the indirection is computed at runtime, we have the freedom to influence the calculation so that the indirection will point to some other class.

The calculation depends on both the class where super is called and on the instance’s tree of ancestors. The first component, the class where super is called, is determined by the source code for that class. In our example, super() is called in the?LoggingDict.__setitem__?method. That component is fixed. The second and more interesting component is variable (we can create new subclasses with a rich tree of ancestors).

Let’s use this to our advantage to construct a logging ordered dictionary without modifying our existing classes:

The ancestor tree for our new class is:?LoggingOD,?LoggingDict,?OrderedDict,?dict,?object. For our purposes, the important result is that?OrderedDict?was inserted after?LoggingDict?and before?dict! This means that the super() call in?LoggingDict.__setitem__?now dispatches the key/value update to?OrderedDict?instead of?dict.

Think about that for a moment. We did not alter the source code for?LoggingDict. Instead we built a subclass whose only logic is to compose two existing classes and control their search order.

_________________________________________________________________________

Search Order

What I’ve been calling the search order or ancestor tree is officially known as the Method Resolution Order or MRO. It’s easy to view the MRO by printing the __mro__ attribute:

If our goal is to create a subclass with an MRO to our liking, we need to know how it is calculated. The basics are simple. The sequence includes the class, its base classes, and the base classes of those bases and so on until reaching?object?which is the root class of all classes. The sequence is ordered so that a class always appears before its parents, and if there are multiple parents, they keep the same order as the tuple of base classes.

The MRO shown above is the one order that follows from those constraints:

• LoggingOD precedes its parents, LoggingDict and OrderedDict

• LoggingDict precedes OrderedDict because LoggingOD.__bases__ is (LoggingDict, OrderedDict)

• LoggingDict precedes its parent which is dict

• OrderedDict precedes its parent which is dict

• dict precedes its parent which is object

The process of solving those constraints is known as linearization. There are a number of good papers on the subject, but to create subclasses with an MRO to our liking, we only need to know the two constraints: children precede their parents and the order of appearance in?__bases__?is respected.

_________________________________________________________________________

Practical Advice

super() is in the business of delegating method calls to some class in the instance’s ancestor tree. For reorderable method calls to work, the classes need to be designed cooperatively. This presents three easily solved practical issues:

• the method being called by super() needs to exist

• the caller and callee need to have a matching argument signature

• and every occurrence of the method needs to use super()

1) Let’s first look at strategies for getting the caller’s arguments to match the signature of the called method. This is a little more challenging than traditional method calls where the callee is known in advance. With super(), the callee is not known at the time a class is written (because a subclass written later may introduce new classes into the MRO).

One approach is to stick with a fixed signature using positional arguments. This works well with methods like __setitem__ which have a fixed signature of two arguments, a key and a value. This technique is shown in the?LoggingDict?example where __setitem__ has the same signature in both?LoggingDict?and?dict.

A more flexible approach is to have every method in the ancestor tree cooperatively designed to accept keyword arguments and a keyword-arguments dictionary, to remove any arguments that it needs, and to forward the remaining arguments using **kwds, eventually leaving the dictionary empty for the final call in the chain.

Each level strips-off the keyword arguments that it needs so that the final empty dict can be sent to a method that expects no arguments at all (for example,?object.__init__?expects zero arguments):

2) Having looked at strategies for getting the caller/callee argument patterns to match, let’s now look at how to make sure the target method exists.

The above example shows the simplest case. We know that?object?has an __init__ method and that?object?is always the last class in the MRO chain, so any sequence of calls to?super().__init__?is guaranteed to end with a call to?object.__init__?method. In other words, we’re guaranteed that the target of the super() call is guaranteed to exist and won’t fail with an?AttributeError.

For cases where?object?doesn’t have the method of interest (a draw() method for example), we need to write a root class that is guaranteed to be called before?object. The responsibility of the root class is simply to eat the method call without making a forwarding call using super().

Root.draw?can also employ?defensive programming?using an assertion to ensure it?isn’t masking some other draw() method later in the chain. ?This could happen if a subclass erroneously incorporates a class that has?a draw() method but doesn’t inherit from?Root.:

If subclasses want to inject other classes into the MRO, those other classes also need to inherit from?Root?so that no path for calling draw() can reach?object?without having been stopped by?Root.draw. This should be clearly documented so that someone writing new cooperating classes will know to subclass from?Root. This restriction is not much different than Python’s own requirement that all new exceptions must inherit from?BaseException.

3) The techniques shown above assure that super() calls a method that is known to exist and that the signature will be correct; however, we’re still relying on super() being called at each step so that the chain of delegation continues unbroken. This is easy to achieve if we’re designing the classes cooperatively – just add a super() call to every method in the chain.

The three techniques listed above provide the means to design cooperative classes that can be composed or reordered by subclasses.

_________________________________________________________________________

How to Incorporate a Non-cooperative Class

Occasionally, a subclass may want to use cooperative multiple inheritance techniques with a third-party class that wasn’t designed for it (perhaps its method of interest doesn’t use super() or perhaps the class doesn’t inherit from the root class). This situation is easily remedied by creating an?adapter class?that plays by the rules.

For example, the following?Moveable?class does not make super() calls, and it has an __init__() signature that is incompatible with?object.__init__, and it does not inherit from?Root:

If we want to use this class with our cooperatively designed?ColoredShape?hierarchy, we need to make an adapter with the requisite super() calls:

_________________________________________________________________________

Complete Example – Just for Fun

In Python 2.7 and 3.2, the collections module has both a?Counter?class and an?OrderedDict?class. Those classes are easily composed to make an?OrderedCounter:

_________________________________________________________________________

Notes and References

*?When subclassing a builtin such as dict(), it is often necessary to override or extend multiple methods at a time. In the above examples, the __setitem__ extension isn’t used by other methods such as?dict.update, so it may be necessary to extend those also. This requirement isn’t unique to super(); rather, it arises whenever builtins are subclassed.

*?If a class relies on one parent class preceding another (for example,?LoggingOD?depends on?LoggingDict?coming before?OrderedDict?which comes before?dict), it is easy to add assertions to validate and document the intended method resolution order:

_________________________________________________________________________

Original Web-link as following:

博主寄語(yǔ)：

文章內(nèi)容略遜文章標(biāo)題，最后貼上Python3.11文檔中關(guān)于super()的說(shuō)明，希望能幫助大家對(duì)super()有更好的理解。不過(guò)，理論需結(jié)合實(shí)踐，還是要多多通過(guò)代碼練習(xí)。

class?super(type,?object_or_type=None)

Return a proxy object that delegates method calls to a parent or sibling class of?type. This is useful for accessing inherited methods that have been overridden in a class.

The?object_or_type?determines the?method resolution order?to be searched. The search starts from the class right after the?type.

For example, if?__mro__?of?object_or_type?is?D?->?B?->?C?->?A?->?object?and the value of?type?is?B, then?super()?searches?C?->?A?->?object.

The?__mro__?attribute of the?object_or_type?lists the method resolution search order used by both?getattr()?and?super(). The attribute is dynamic and can change whenever the inheritance hierarchy is updated.

If the second argument is omitted, the super object returned is unbound. If the second argument is an object,?isinstance(obj,?type)?must be true. If the second argument is a type,?issubclass(type2,?type)?must be true (this is useful for classmethods).

There are two typical use cases for?super. In a class hierarchy with single inheritance,?super?can be used to refer to parent classes without naming them explicitly, thus making the code more maintainable. This use closely parallels the use of?super?in other programming languages.

The second use case is to support cooperative multiple inheritance in a dynamic execution environment. This use case is unique to Python and is not found in statically compiled languages or languages that only support single inheritance. This makes it possible to implement “diamond diagrams” where multiple base classes implement the same method. Good design dictates that such implementations have the same calling signature in every case (because the order of calls is determined at runtime, because that order adapts to changes in the class hierarchy, and because that order can include sibling classes that are unknown prior to runtime).

For both use cases, a typical superclass call looks like this:

In addition to method lookups,?super()?also works for attribute lookups. One possible use case for this is calling?descriptors?in a parent or sibling class.

Note that?super()?is implemented as part of the binding process for explicit dotted attribute lookups such as?super().__getitem__(name). It does so by implementing its own?__getattribute__()?method for searching classes in a predictable order that supports cooperative multiple inheritance. Accordingly,?super()?is undefined for implicit lookups using statements or operators such as?super()[name].

Also note that, aside from the zero argument form,?super()?is not limited to use inside methods. The two argument form specifies the arguments exactly and makes the appropriate references. The zero argument form only works inside a class definition, as the compiler fills in the necessary details to correctly retrieve the class being defined, as well as accessing the current instance for ordinary methods.

For practical suggestions on how to design cooperative classes using?super(), see?guide to using super().

一起學(xué)習(xí)，共同進(jìn)步