There are definite advantages to Python's typing policy, sometimes called "duck typing." If an object has methods "waddle" and "quack" then it's safe to treat it like a duck.
Or is it?
For duck-specific terms like "waddle" and "quack", it's fairly safe to assume that objects supporting methods with those names are sufficiently duck-like to be treated as such. But what about a method named "twist"? Does it belong to a dancer, a bartender, or does it have something to do with a 4D complex Weyl spinor representation?
That's a fabricated example, but the example I mentioned in the previous entry isn't. There is more to identity than syntax.
One solution to the problem of distinguishing lists from strings would be to check for the index operator, and then check for some string-supported method to decide if something was a string or a list. Although it would have worked in the context of the problem I was facing, it is in general a very bad idea. It makes some very strong assumptions about what kind of objects are out there, and reminds me of nothing so much as the penchant for Web developers to try to decide what browser their Javascript is running on by checking for a few well-known methods that only have single-browser support at the moment.
The other thing it reminds me of are the various "terrorist watch lists" floating around these days, like the FAA's "No Fly List." People sometimes say that the No Fly List has a million people on it, but this is false. It has a million (plus, and growing) names on it, but having the same name as a Maryland peace activist does not mean you share that person's beliefs.
So while I appreciate the enormous flexibility of the Python type system, to use it well requires sensitivity and taste, like so much else in software development. Or one might wind up sending entirely the wrong code to Gauntanamo.
Or is it?
For duck-specific terms like "waddle" and "quack", it's fairly safe to assume that objects supporting methods with those names are sufficiently duck-like to be treated as such. But what about a method named "twist"? Does it belong to a dancer, a bartender, or does it have something to do with a 4D complex Weyl spinor representation?
That's a fabricated example, but the example I mentioned in the previous entry isn't. There is more to identity than syntax.
One solution to the problem of distinguishing lists from strings would be to check for the index operator, and then check for some string-supported method to decide if something was a string or a list. Although it would have worked in the context of the problem I was facing, it is in general a very bad idea. It makes some very strong assumptions about what kind of objects are out there, and reminds me of nothing so much as the penchant for Web developers to try to decide what browser their Javascript is running on by checking for a few well-known methods that only have single-browser support at the moment.
The other thing it reminds me of are the various "terrorist watch lists" floating around these days, like the FAA's "No Fly List." People sometimes say that the No Fly List has a million people on it, but this is false. It has a million (plus, and growing) names on it, but having the same name as a Maryland peace activist does not mean you share that person's beliefs.
So while I appreciate the enormous flexibility of the Python type system, to use it well requires sensitivity and taste, like so much else in software development. Or one might wind up sending entirely the wrong code to Gauntanamo.
