On 08/06/13 13:12, Rui Maciel wrote: > Joshua Landau wrote: > >> What's the actual problem you're facing? Where do you feel that you >> need to verify types? > A standard case would be when there's a function which is designed expecting > that all operands support a specific interface or contain specific > attributes. > > In other words, when passing an unsupported type causes problems. >
Hi, First, let's get over the fact that, with dynamic typing, code fails at runtime. Irrespective of language, you just shouldn't ship untested code, so I say that's not an argument against dynamic typing. This behaviour is only a problem when code fails *too late* into the runtime -- i.e. when you don't see the offending value in the stack trace. For example, consider you append values to a list and the values in that list get processed somewhere else. If your code fails because of an invalid value, your stack trace is useless, because that value should not be there in the first place. The code should fail when appending to that list and not when processing it. The "too late" case is a bit tough to illustrate. This could be a rough example: https://gist.github.com/plq/6163839 Imagine that the list there is progressively constructed somewhere else in the code and later processed by the sq_all function. As you can see, the stack trace is pretty useless as we don't see how that value got there. In such cases, you do need manual type checking. Yet, as someone else noted, naively using isinstance() for type checking breaks duck typing. So you should read up on abstract base classes: http://docs.python.org/2/glossary.html#term-abstract-base-class These said, I've been writing Python for several years now, and I only needed to resort to this technique only once. (i was working on a compiler) Most of the time, you'll be just fine without any manual type checking. Best regards, Burak -- http://mail.python.org/mailman/listinfo/python-list
