Linked by Thom Holwerda on Mon 14th Jan 2013 23:15 UTC, submitted by MOS6510
Permalink for comment 549115
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



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.