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/ -- http://mail.python.org/mailman/listinfo/python-list
