[Python-ideas] ABC: what about the method arguments ?

[Tarek Ziadé]

On Thu, Sep 23, 2010 at 8:01 PM, Antoine Pitrou <solipsis at 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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Tarek Ziadé | http://ziade.org