Sturla Molden wrote: > Python will no longer be dynamic, it will just be a slow static language.
It is worth explaining why this is wrong. First, we need some definitions. A *statically typed language* is one where variables have a type known to the compiler at compile-time. That may be because the programmer declares the type like in C: int n = 23; or because the compiler can logically derive the type, like in Haskell: n = 23 (the compiler knows that 23 is an int, not a string or a Widget or a list, and therefore on the assumption that you know what you are doing, n must be an int too). Later, when you go to do an operation on n: n.append('foo') the compiler knows that this must be an error, because n is an int, and ints don't have an append method. And when you go to do an assignment: n = 'foo' the compiler will prevent it because n is an int variable, not a string variable. In *dynamically typed languages*, variables don't have types, but *values* do. Since variables don't have types, the compiler won't prevent you from re-assigning a string to the same name that once held an int: n = 23 n = 'foo' but nor can it tell at compile time that n is an int and doesn't have an append method. The way it tells is to wait until runtime and then attempt to call the append method and see if it fails. But... that's not a law of physics. Just because dumb compilers are dumb doesn't mean that you can't have smarter compiles. 30 years ago the state of the art for dynamic languages like Lisp and Smalltalk was good enough to reason about type errors just as well as we human beings can. If we see: n = 23 n.append('foo') we know that this is going to fail. We don't need to run the code because we can reason that at the time n.append is called, n is bound to an int and ints don't have append methods. That's not very hard. Even Barry the intern can do that, why can't Python? Why can't Python tell me that 1+"1" will fail ahead of time? Even in languages like C, the type-checking is done during a separate phase of compilation, before code generation. So we can split the code-checker out from the compiler, and make it a separate program which analyses the source code, and stick it in your editor or IDE. Now when you start to type: L = [] L.appe the IDE can guess that L is a list, and offer to auto-complete "append". But given n.appe it can predict that n isn't a list, and flag the word in red or beep or something, depending on how annoying it wants to be. Or you can run the type-checker as a separate program, like a linter or PEP-8 checker, and it will analyse the source code and point out that on page 2 you assign n=23 and then on page 4 you call n.append but nowhere in the intermediate code was n reassigned to a list. If this was Java, the compiler would refuse to generate code while there are any compile-time errors. But this is Python, and the type-checker is a separate tool, so you can ignore it and run your script and sure enough you will get an AttributeError when it tries to call n.append. Because maybe you wanted an AttributeError. This doesn't remove the dynamicism from the language. It's still dynamically typed, it still has powerful runtime features. You won't even have to declare types for everything if you don't want to. -- Steven -- https://mail.python.org/mailman/listinfo/python-list