D H said:
Even if Pythonistas are the most thorough of all testers, it is a stupid concept. The earlier errors are caught the cheaper it is to repair them. This approach defers error detection until testing, or even worse, post deployment.
D H,you're missing the coding train in more ways than one. One of the most central tenets of Python is
duck typing, which means that a given object's current set of methods, fields, etc. determine how it can be used. Objects in Python do not have explicit types; instead, if they express the methods and fields of a some type A, then they can be used as if they were type A. There's no reason to give objects explicit strong types, because most of the objects people write in the real world naturally end up being multi-faceted anyway.
This mechanism is
just as strong as actual strong typing, yet provides enormous flexibility. It allows any object to be used in any desired way simply by defining the appropriate methods or fields. You want your data structure to be iterable? Just define a few methods. Any code that attempts to use your data structure in an unintended way will generate a run-time error, which can be caught and handled appropriately.
Strong typing doesn't necessarily make code less bug-prone, and I challenge you to find any studies that claim such a thing. Strong typing is just a poor man's substitute -- an easy to implement, but unduly restrictive substitute -- for real introspection, where one piece of code is actually
aware of what another piece of code can do.
That's not to say that strong typing does not have its place. If I were writing code that goes into aircraft avionics, I'd definitely be using a language with strong typing, because it prevents the (extremely rare) possibility of misusing an object that just happens to define methods to make it look like something it is not. In practice, I have never run across such an "impostor" object in years of programming Python, so it's really a non-issue.
- Warren
