duck-type-checking?

[Steven D'Aprano]

On Thu, 13 Nov 2008 14:28:49 +0100, paul wrote:

> Ben Finney schrieb:
>> Joe Strout <joe at strout.net> writes:
>>> "x quacks like a basestring if it implements all the public methods of
>>> basestring, and can be used in pretty much any context that a
>>> basestring can."
>> 
>> That is not duck typing. Rather than checking what foo does in response
>> to prodding that, by your admission, is only designed to find out what
>> type it is, duck typing instead advocates that you should use foo *as
>> though it is known to be* the type of object you want. If it is not
>> suitable, then appropriate exceptions will be raised and either caught
>> by some code that knows how to handle them, or crash the program.
> 
> Warning, rant ;)
> 
> This whole theory breaks down quickly if you're writing library code.
> How do your unittests help the user of your library to use it correctly?

They don't. Unittests don't help you get better fuel economy for your car 
either. Neither of those things are the purpose of unittests.


> How do you communicate incorrect usage of your interfaces to the user?

With documentation and exceptions.

 
> If you are able to specify the type of the arguments as part of the
> interface the compiler/interpreter will help you.

Not in Python it won't. You can argue that this is a weakness of Python, 
and you might even be correct (arguably, for some definition of 
"weakness"), but it is by design and won't change anytime soon, not even 
with ABCs.


> Types are used to
> describe behaviour (if thats a good thing, I don't know).

Types are one way of specifying behaviour, although they are subject to 
false negatives and false positives. For example, type Spam may have the 
exact same behaviour and interface as type Ham, but if the compiler has 
been instructed to reject anything that is not Ham, it will wrongly 
reject Spam. This is one of the problems duck-typing is meant to 
ameliorate.

[snip rest of rant, which seemed incoherent to me]



-- 
Steven