On Thu, Sep 23, 2010 at 8:01 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le jeudi 23 septembre 2010 à 19:51 +0200, Tarek Ziadé a écrit :
On Thu, Sep 23, 2010 at 6:32 PM, Antoine Pitrou <solipsis@pitrou.net> wrote: ...
This feature already exists, as you mention, using issubclass() or isinstance(). What you are asking for is a different feature: check that a class has an appropriate implementation of the advertised capabilities. Traditionally, this is best left to unit testing (or other forms of test-based checking).
Do you have an use case where unit testing would not be appropriate for this?
Why are you thinking about unit tests ? Don't you ever use issubclass/isinstance in your programs ?
Sorry, you don't seem to be answering the question. Why wouldn't the implementor of the class use unit tests to check that his/her class implements the desired ABC?
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?
Checking signatures using ABC when you create a plugin system is one use case for instance.
Again, why do you want to check signatures? Do you not trust plugin authors to write plugins?
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. Checking the methods, and optionally their attributes is just a deeper operation on something that already exists. It's fine to use those only in your tests, but why do you object that someone would want to use them in their app. This is completely orthogonal to the discussion which is: extend a method checker to check attributes.
It depends on the arguments. And the implementation could definitely use *args or **kwargs arguments, especially if it acts as a proxy.
Sure but ISTM that most of the time signatures are well defined, and proxies lives in an upper layer.
Not really. If I write a file object wrapper that proxies some methods to an other file object, I don't want to re-type all method signatures (including default args) by hand.
In that case I am curious to see why you would have file I/O method with extra *args/**kwargs. You should handle this kind of set up in the constructor and keep the methods similar. (and avoid extra re-type actually) Regards Tarek
Regards
Antoine.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Tarek Ziadé | http://ziade.org