To view parent comment, click here.
To read all comments associated with this story, please click here.
Your cat example was simple, so it deserves a simple implementation. If you'd wanted me to model the complete biological workings of a cat; that'd be an example of a complex model that would very much have components that differ in type. And I'd almost certainly want them to be strongly typed; no using a lung as a leg!
All current development models fail horribly at modeling the real world. Weak typing gives you no leverage here. Dynamic typing gives you no leverage. Structured, functional, or object oriented paradigms give you no leverage. The world is a messy graph that you can't simplify into something nice and neat.
Python is a strong language. There isn't any debate about this. It's simply a fact.
The "cat" example was simple object yet most type systems would fail to classify it properly. Real objects have multiple "types" in many hierarchies, often changing over time.
As for python - there was never any debate about it. It has always been a weakly typed language by most definitions (admittedly, not yours). In fact, Guido had to often defend his choice against legions of people who prefer strong typing:
http://www.artima.com/intv/strongweak.html





Member since:
2009-06-30
No generalizations are valid. Especially when there are whole groups of people thinking otherwise (here: for very concrete reasons prefer weak typing to strong typing in nearly all cases).
Strong typing works extremely well with abstract single-function objects (a number, a string, a list, a set) and fails *badly* at any attempt of modeling real objects. In a way, you have admitted that yourself - a "cat" from my example would be an "Object" type, distinguished only by its fields, not the type.
Strong typing implies enforcement, otherwise it wouldn't be "strong". Preferably at compile time, and at least at runtime, although many advocates of strong typing would disagree with that. The problem with your example is that Python doesn't even enforce types at runtime - a "type" (class) is just a method of reusing implementation. At runtime the interpreter is only interested whether the field/method you're accessing is defined or not - something that may and does change at any the time.