That is not a new idea. So far I have always rejected it because I worry about both false positives and false negatives. Trying to enforce that the method *behaves* as it should (or even its return type) is hopeless; there can be a variety of reasons to modify the argument list while still conforming to (the intent of) the interface. I also worry that it will slow everything down.
That said, if you want to provide a standard mechanism that can *optionally* be turned on to check argument conformance, e.g. by using a class or method decorator on the subclass, I would be fine with that (as long as it runs purely at class-definition time; it shouldn't slow down class instantiation or method calls). It will probably even find some bugs. It will also surely have to be tuned to avoid certain classes false positives.
On Thu, Sep 23, 2010 at 7:37 AM, Tarek Ziadé email@example.com wrote:
ABC __subclasshook__ implementations will only check that the method is present in the class. That's the case for example in collections.Container. It will check that the __contains__ method is present but that's it. It won't check that the method has only one argument. e.g. __contains__(self, x)
The problem is that the implemented method could have a different list of arguments and will eventually fail.
Using inspect, we could check in __subclasshook__ that the arguments defined are the same than the ones defined in the abstractmethod.-- the name and the ordering.
I can even think of a small function in ABC for that: same_signature(method1, method2) => True or False
-- Tarek Ziadé | http://ziade.org _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas