"Super()" confusion

Paul Boddie paul at boddie.org.uk
Tue Feb 10 23:59:35 CET 2009

On 10 Feb, 20:45, Jean-Paul Calderone <exar... at divmod.com> wrote:
> It replaces one kind of repetition with another.  I think each kind is
> about as unpleasant.  Has anyone gathered any data on the frequency of
> changes of base classes as compared to the frequency of classes being
> renamed?  I don't think either happens very often, but it might be
> interesting to see some numbers.

Base class changes are less important than common derived class
functionality. For example, I have employed the following style of
class hierarchy in at least one system:

class ResourceUsingClass:

    Stuff using some resource, like a file.
    Should we close the file when we're finished with it?
    Is that rude? Best not do it!

    def close(self):
        pass # Don't close anything!

class SelfContainedResourceUsingClass(ResourceUsingClass):

    We don't care about keeping the resource open in this class.
    The user of the class should just need to call the close method.

    def close(self):
        # Now close the resource!

I know that there would be other ways of solving this problem, but in
this case, for every class we want to subclass and provide such
functionality, we need to write a specific close method. With super,
we can avoid being specific about the superclass, but we still need to
write the method unless we define it in a mix-in which appears before
the superclass in the method resolution order.

I think this is the only real use I've found for super, mostly
because, as you say, in most other situations it doesn't actually save
anyone very much effort.


More information about the Python-list mailing list