cat /dev/brain

You may have already heard about this, but Guido van Rossum has co-authored PEP 484 [1] to standardize a basic set of Type Hints. If you've heard of PEP 484 already, this probably isn't the one-line summary you've heard about. In fact, if you've heard about this already, you've probably heard about a dystopian future where the code in your .py files is unreadable and incomprehensible and everyone is doomed.

This particularly bothers me. There are a group of "elders" [2] who are very vehemently opposed to the idea of providing any such features that would make using Type Hints (which were introduced years ago in 3.0) actually practical and usable. Of course, this isn't how they see PEP 484. They see PEP 484 as the recreation of C++ in Python, or Haskell in Python.

If you're wondering what all of this means, here's the reality:

• PEP 484 does not change the language so as to require you to include Type Hints
• PEP 484 does not change the language such that when you type python3.5 my_file.py it gives you TypeErrors before it actually runs your code
• PEP 484 does not include any tooling to check the types that you've included in your .py file(s)
• PEP 484 does not prescribe the use of Type Hints in all Python code
• PEP 484 does not turn Python into a statically typed language (i.e., Python will still be a dynamically typed language)
• PEP 484 does not provide primitives that can be used in conjunction with duck-typing
• PEP 484 does not require CPython to implement runtime checks using your type annotations
• PEP 484 does provide ways for you to create and use better Type Hints in your code that can support it
• PEP 484 does standardize an extension to be used for "stub" files [3]
• PEP 484 does provide a standard syntax for type hints
• PEP 484 does take advantage of the existing type annotation syntax in Python 3
• PEP 484 does prescribe a way to do type aliasing
• PEP 484 does provide a new module (typing) that contains several class-like types for use in type hints
• PEP 484 does specify exactly what will be in the new typing module
• PEP 484 does provide generics
• PEP 484 does provide a way for users to define generics and types
• PEP 484 does provide a syntax for adding types to variable definitions via comments.

This just scratches the surface of what's in the PEP though. That said, there is nothing in it that is nefarious in intent or action. If you choose not to read the PEP, you should at least read this:

It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.

In other words, all the tales of the demise of Python as we know it are a way of generating fear, uncertainty, and doubt. I don't know why these people would choose to do this, but I can only assume that they haven't read the PEP. An alternative explanation is that they spent a couple hours with Haskell or Rust and couldn't stomach either one and now they're afraid of Python turning into one or the other.