Noam Raphael <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
