"Stephen R Laniel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] || Reading [1], I wonder: why isn't the compiler making better | use of (purely optional) type labeling? Why not make a compiler | directive so that | | a) it will check the types of all my arguments and return | values, and maybe even | b) do some type inference up the call stack? | | E.g., | | def( Class1 arg1, Class2 arg2, ..., ClassN argN ): | someStuff() | | would check the types of the arguments, whereas | | def( arg1, arg2, ..., argN): | someStuff() | | would not? I.e., if I *want* strong static | type-checking, why shouldn't I be able to get it?
1. Type checking arguments at compile time requires that the types of arguments be known at compile time. Since arguments often are either names or expressions using names, this would require that names be typed and that all assigments to names be type-checked. In other words, static typing pretty much all the way. 2. Python has multiple implementations. Any requirement such as this would be a requirement on all. It is possible that there will be some implementation that does something of what you want while the others continue as they are. Or that there will be third-party add-ons (like psyco today). 3. There are multiple possible uses of type annotations: documentation, speed, error checking, and maybe others yet to be thought of. Mandating any particular use would be a burden to anyone only interested in other uses. As an old-timer, I also do not initially see the point of annotation with no (required) effect. But then I realized point 3 above. I believe that the statement you interpreted as 'forbidding' static typing was Guido's promise that annotations will *not* be a step towards turning Python into something else -- a staticly typed language. That is important to the many people who use Python *because* it is dynamically and not statically typed and who consider that a net benefit. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
