>>25
No need for my/strict in Python, as the use of an undefined symbol raises an exception.
The 5-10 times more productivity comes from several things: dynamic typing, no time spent on managing types, builtin lists and dictionaries, functional programming features, expresiveness of the language, dynamic extensibility, and the generic nature of anything you write. For the same price, something that would work on X will also work on Y, Z, and the whole alphabet, without having to consider polymorphism rules or anything - you call method hi, and objects have method hi, as simple as that.
BTW, 50 MB of Python? You could program all vital systems of a space station with that.
>>27, yes, dynamic typing can be troublesome when you call method "hi" of object "x" because it might not be evident what "x" is in real time, but if you write proper code, you should be able to tell what kind (note the use of "kind" instead of "type") of objects x will be from its name and from the context (e.g. function it's done in). That's why you avoid one-character names for important objects. If you can't tell the kind of an object by its name or immediately accessible documentation near the function definition, you're doing something wrong (or the guy who wrote that did something wrong).
Also, QUACK.
>>29
I was thinking the same thing.