Jan 062016

I personally don’t like Python’s type annotations, the completely mask out what was a human friendly function signature. For something that was being proposed and skunk-worked in to stub files, according to Guido’s keynote at PyCon, it is spreading inside of source files, at an alarming rate, through out Python’s upper echelon.

Just this weekend Type Annotations infested a blog post on Why print is now a function in Python 3. Luckily Brett, took out the hedge trimmers and cleared away the mess. It is a interesting blog post now that you can see what he is talking about. Now I see that they’ve spread to PEP8.

The usefulness of Static Type Checking against Dynamic code is questionable at best. The damage that can and may be done to readable function signatures is frightening on scale similar to the Kudzu infestation and decimation of indigenous plants in the US. I encourage you to help fight this invasive and damaging trend by keeping your Type Annotations where they belong, in stub files.

Why doesn’t PEP8 encourage the use of stub files over obfuscating your code? A considerable number of people don’t like lint droppings ( # pylint:disable=… ) in their code and it goes in a comment, this trash is being put right in the function’s signature.

What is the practical upside to Static Type Checking? Guido talked about it in big terms and hand waving, in his keynote and people use glowing buzz words, but, seriously with examples, what can it actually do that writing testable code and tests can’t? The upside is as hard to see as a type annotated signature.

 Posted by at 6:13 pm

  3 Responses to “Type Annotations: The Kudzu of Python?”

  1. Thank you for this insightful post. You asked what the practical upside would be for static type checking. It’s yet another safety net which will reduce the number of programming errors, usually even before running your test suite. It has helped me avoid a number of errors by pointing out my mistakes as I type the code.

    I should point out that maintaining the stub files would be a total PITA due to the duplication of effort, and personally I have no problem reading the function signatures. So yes, I’m going to keep adding type annotations to ALL my functions and recommending others to do so as well. And there’s sphinx-autodoc-typehints which will make them more readable in the generated API documentation.

  2. @Alex, I use pylint and am looking for specific cases where Type Annotations would catch an error that pylint + tests would not. I believe that stub files are a better way. Stubs are for programs, source is for people. Mixing the two creates an unwanted kudzu effect. So I am still not convinced that the loss of readability is offset by these still undocumented errors that are not catchable by other means is a win.

    Do you also use tests in your development work flow?

  3. Yes, I use tests and I strive for 100% code coverage.

    I think type annotations make code unreadable for you because you’re not used to their presence. If it was universal they’d bother me too. Most annotations are simple types like str or int anyway.

    My use of type annotations has four goals:
    1) Make the code easier to comprehend (yes!)
    2) Enable PyCharm to show me more precise errors as I type and to enable autocompletion when type inference fails
    3) Act as an additional safety net (using typeguard)
    4) Assist in automatic generation of API documentation (using sphinx-autodoc-typehints) so I don’t have to use Sphinx’s :type: directive or add the types in :param: directive

Sorry, the comment form is closed at this time.