On 10 Feb, 20:45, Jean-Paul Calderone <[email protected]> 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
