How about "pure virtual methods"?

[Noam Raphael]

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.
> 
>      <mike

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 
easier...)

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.

Noam