Mario Figueiredo wrote: > Static analysis cannot and should not clutter executable code.
(1) It isn't clutter. The human reader uses that information as well as the compiler, interpreter, type-checker, IDE, text editor, correctness tester, etc. (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens (hundreds?) of other languages disagree with you. > Let [type-hints] reside in comments, docstrings, external files, whatever. Didn't you criticise the use of type-hints in comments earlier? Or am I confusing you with somebody else? > I'm actually baffled that PEP 484 came into existence, let alone it > having any kind of supporter. Here we have a syntax that even requires > changes to the interpreter so it can safely ignore all the type hinting > clutter that is going to be added by anyone wanting to perform static > analysis. That *absolutely is not true*. I don't know where you get this from. Python 3 has supported function annotations for over five years now. The only change required with PEP 484 is to give those annotations a standard meaning and encourage people to use them for type-checking instead of whatever other uses they have or haven't (mostly haven't) thought of. > The requirements > for PEP 484 are heavy. Not only will they force an update to the > interpreter, but will also force many users to reformate their function > headers in order for them to become bareable to the eye. In fact, no > longer will you look at function definitions like you did before. Again, this is wrong. PEP 484 requires *no* update to the interpreter. It adds a single library file to the standard library, but use of that is optional. It requires *nobody* to rewrite or reformate their function headers. The only people who will do so are those who want to run type-checkers which support type-hints. -- Steven -- https://mail.python.org/mailman/listinfo/python-list