How about "pure virtual methods"?
noamr at remove.the.dot.myrea.lbox.com
Fri Dec 24 00:38:07 CET 2004
Mike Meyer wrote:
> Noam Raphael <noamr at remove.the.dot.myrea.lbox.com> writes:
>>The answer is that a subclass is guaranteed to have the same
>>*interface* as the base class. And that's what matters.
> This is false. For instance:
> class A(object):
> def method(self, a):
> print a
> class B(A):
> def method(self, a, b):
> print a, b
> B implements a different interface than A. Statically typed OO
> languages either use multi-methods or disallow changing the signature
> of an overridden method.
> A tool to detect such cases would probably be almost as useful as the
> tool you've proposed.
I agree that such a tool would be very useful. In fact, I think it
exists - I'm sure pychecker checks for mistakes like that. I understand
that it checks for not implementing functions which just raise an
exception too, so you can say, "why all this mess? Run pychecker and
everything will be good." However, I think that there is a difference
between these two tests, which explains why one should be done by the
language itself and one should be done by an analysis tool.
The difference is that handling arguments, in Python, can be seen as a
part of the *implementation*, not the interface. The reason is that you
can write a method which simply gets a (*args, **kwargs), and raises a
TypeError if the number of args isn't two, and it would be completely
equivalent to a function which is defined using def f(a, b). Of course,
even in statically typed languages, you can't enforce an implementation
to do what it should (too bad - it would have made debugging so much
So checking whether the argument list of a method of a subclass suits
the argument list of the original implementation is nice, but should be
left to external analysis tools, but checking whether a method is
defined at all can be done easily by the language itself.
More information about the Python-list