Le jeudi 23 septembre 2010 à 20:59 +0200, Tarek Ziadé a écrit :
That's fine indeed. Now, why wouldn't the implementor of an application use ABC to check that the third party class he's about to load in his app implements the desired ABC?
Why would he? What does it provide him exactly? A false sense of security / robustness?
Also, why do you think checking signatures is actually useful? It only checks that the signature is right, not that the expected semantics are observed. The argument for checking method signature in advance is as weak as the argument for checking types at compile time.
Sorry but it seems that you are now advocating against ABC altogether.
As I said, I believe ABCs are useful mainly for documentation purposes; that is, for conveying an /intent/. Thinking that ABCs guarantee anything about quality or conformity of the implementation sounds wrong to me. (the other reason for using ABCs is to provide default implementations of some methods, like the io ABCs do)
This is completely orthogonal to the discussion which is: extend a method checker to check attributes.
It's not really orthogonal. I'm opposing the idea that programmatically checking the conformity of method signatures is useful; I also think it's *not* a good thing to advocate to Python programmers coming from other languages.
In that case I am curious to see why you would have file I/O method with extra *args/**kwargs.
def seek(self, *args): return self.realfileobj.seek(*args)
So are you in favor of the removal of all kind of type checking mechanism in Python ?
"Type" checking is simply done when necessary. It is duck typing. Even in the case of ABCs, method calls are still duck-typed. For example, if you look at the io ABCs and concrete classes, a BufferedReader won't check that you are giving it a RawIOBase to wrap access to. Regards Antoine.