On 10 Feb, 20:45, Jean-Paul Calderone <exar...@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): ResourceUsingClass.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. Paul -- http://mail.python.org/mailman/listinfo/python-list