cat /dev/brain

Type Hints in Python 3.5

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.

What does this mean for Requests?

Cory and I have both been involved in the discussions around PEP 484. We both agree that even with the typing module in 3.5, type hints will not be mature enough to represent the complexity of Requests' API. Requests relies heavily on duck-typing and without a much more advanced set of type hints in the typing module, it will be very difficult for us to implement a maintainable and accurate set of stub files for the module.

We are not ruling out the possibility of creating stub files in the future. We are of the position that the current primitives are not enough and Guido has acknowledged this himself.

I will, however, definitely be toying with Type Hints in stub files for other projects of mine. I'm very interested to see how these could improve the developer experience with github3.py or betamax.

There are no comments on this blog. If someone posts it to reddit, I might notice it and discuss it with you in the comments there. Otherwise, feel free to email me or tweet your responses to me.
[1]Python Enhancement Proposal
[2]For lack of a better word. These are just people who have been around the python community a long time.
[3]Stub files are for C-extensions and Python files meant to be used on Python 2 and 3. They provide Type Hints for checkers like mypy without causing the code to be syntactically invalid on Python 2