On Thu, Sep 23, 2010 at 4:53 PM, Guido van Rossum firstname.lastname@example.org wrote:
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.
I'll experiment on this and come back :)