From comments below...
How is the argument from reliability of Lisp and Erlang systems an argument against optional static type declarations?The real question is, should optional type annotations be added to Python? I'd say no, the return on investment is not nearly as great as investing in several other implementation features.
In the Lisp world, you program with dynamic typing initially until the program stabilizes and the hot spots are known. You then type annotate just the hot spots to improve code generation of those hot spots (Lisp code is generally compiled), with the option to go to C to improve the hottest of the hot spots.Optional type annotations were added to Common Lisp in the early 1980's. Compiler strategies have improved a lot since then, as have machine capabilities. I think a better return would come from investing in the implementation of the current Python language rather than changing the Python language itself.
Basically, type annotations in Lisp (and, one presumes, Python) are an upside option that you can but don't have to use. Writing Python code (or Lisp code) from scratch with type annotations would be pretty silly. (Or, to put this another way, in Lisp type annotation is a performance, not a reliability feature).I think the downside of having every Python programmer have to understand the best practices of optional type annotations would be far worse than the upside of having them. To repeat myself, the investment should be made "under the hood" of the current Python language.