duck-type-checking?

[Steve Holden]

greg wrote:
> Joe Strout wrote:
>> This is not hypothetical -- just last week I had a hard-to-track-down 
>> abend that ultimately turned out to be an NLTK.Tree object stored 
>> someplace that I expected to only contain strings.  I found it by 
>> littering my code with assertions of the form 
>> isinstance(foo,basestring).
> 
> But you have to ask yourself whether the time taken to
> write and maintain all these assertions is really
> cost-effective. In my experience, occurrences like this
> are actually extremely rare -- the vast majority of the
> time, you do get a failure very quickly, and it's fairly
> obvious from the traceback where to look for the problem.
> 
> It's as annoying as hell when something like this does
> happen, but averaged over the lifetime of the project,
> I find it doesn't cost all that much time.
> 
This is particularly true since Joe is still proposing to check the
objects when they are passed to functions and methods that use them.
Unfortunately the assignment of the "wrong type of object" may well have
taken place aeons ago, and it's the assignments you really need to catch
(and it's also the assignments that static languages cause compile
errors on).

So it hardly matters whether the code blows up with

  Exception: my expensive type checks sounded an alarm

or

  Attribute error: foo has no method bar()

since both are equally informative when it comes to tracing the faulty
assignment.

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/