Python’s “Type Hints” are a bit of a disappointment to me

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • JetBrains - Developer Ecosystem Survey 2022
  • pyright

    Static type checker for Python

    Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

    Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

    > type hints are not binding.

    There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

    It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

    > Type checking is your job after all, ...[and that] requires maintenance.

    There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

    > There is an Any type and it renders everything useless

    I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

    > Duck type compatibility of int and float

    The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

    > Most projects need third-party type hints

    Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

    > Sadly, dataclasses ignore type hints as well

    Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

    > Type inference and lazy programmers

    The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

    > Exceptions are not covered [like Java]

    I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

    [0] https://github.com/RussBaz/enforce

    [1] https://github.com/agronholm/typeguard

    [2] https://github.com/microsoft/pyright

    [3] https://pydantic-docs.helpmanual.io

    [4] https://github.com/tiangolo/fastapi

    [5] https://github.com/microsoft/pyright/blob/main/docs/configur...

    [6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

  • mypy

    Optional static typing for Python

    It reminds me of this 5 year old bug in mypy: "int is not a Number?" [1].

    [1]: https://github.com/python/mypy/issues/3186

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • beartype

    Unbearably fast O(1) runtime type-checking in pure Python.

  • returnn

    The RWTH extensible training framework for universal recurrent neural networks

    > warnings of IDEs are simple to ignore

    This is unusual. In my experience, of codebases I have worked with or have seen, when there are type hints, there are almost all perfectly correct.

    Also, you can setup the CI to check also for IDE warnings. For example, we use this script for PyCharm: https://github.com/rwth-i6/returnn/blob/master/tests/pycharm...

    The test for PyCharm inspections only passes when there are no warnings.

    Although, I have to admit, we explicitly exclude type warnings because here we have a couple of false positives. So in this respect, it actually agrees with the article.

    But then we also do code review and there we are strict about having it all correct.

    Yes, I see the argument of the article that the typing in Python is not perfect and you can easily fool it if you want, so you cannot 100% trust the types. But given good standard practice, it will only rarely happen that the type is not as expected and typing helps a lot. And IDE type warnings, or mypy checks still are useful tools and catch bugs for you, just not maybe 100% of all typing bugs but still maybe 80% of them or so.

    > Isn’t it better to detect at least some errors than to detect none at all?

  • Nim

    Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

    > What I want is this: Some language that’s as easy to use as Python and it should be compiled and with good static typing...

    Well, there's always Nim. [0]

    > ...but it should also not be compiled because then it wouldn’t be as easy to use as Python anymore. Whoops?

    Eh, there's Nimscript? [1]

    0. https://nim-lang.org/

  • cinder

    Cinder is Meta's internal performance-oriented production version of CPython. (by facebookincubator)

    This article captures a lot of the rationale behind why we're building Static Python within Cinder: https://github.com/facebookincubator/cinder#static-python

  • enforce

    Python 3.5+ runtime type checking for integration testing and data validation

    Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

    Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

    > type hints are not binding.

    There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

    It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

    > Type checking is your job after all, ...[and that] requires maintenance.

    There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

    > There is an Any type and it renders everything useless

    I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

    > Duck type compatibility of int and float

    The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

    > Most projects need third-party type hints

    Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

    > Sadly, dataclasses ignore type hints as well

    Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

    > Type inference and lazy programmers

    The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

    > Exceptions are not covered [like Java]

    I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

    [0] https://github.com/RussBaz/enforce

    [1] https://github.com/agronholm/typeguard

    [2] https://github.com/microsoft/pyright

    [3] https://pydantic-docs.helpmanual.io

    [4] https://github.com/tiangolo/fastapi

    [5] https://github.com/microsoft/pyright/blob/main/docs/configur...

    [6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • pydantic

    Data parsing and validation using Python type hints

    Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

    Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

    > type hints are not binding.

    There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

    It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

    > Type checking is your job after all, ...[and that] requires maintenance.

    There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

    > There is an Any type and it renders everything useless

    I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

    > Duck type compatibility of int and float

    The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

    > Most projects need third-party type hints

    Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

    > Sadly, dataclasses ignore type hints as well

    Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

    > Type inference and lazy programmers

    The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

    > Exceptions are not covered [like Java]

    I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

    [0] https://github.com/RussBaz/enforce

    [1] https://github.com/agronholm/typeguard

    [2] https://github.com/microsoft/pyright

    [3] https://pydantic-docs.helpmanual.io

    [4] https://github.com/tiangolo/fastapi

    [5] https://github.com/microsoft/pyright/blob/main/docs/configur...

    [6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

  • typeguard

    Run-time type checker for Python

    Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

    Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

    > type hints are not binding.

    There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

    It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

    > Type checking is your job after all, ...[and that] requires maintenance.

    There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

    > There is an Any type and it renders everything useless

    I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

    > Duck type compatibility of int and float

    The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

    > Most projects need third-party type hints

    Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

    > Sadly, dataclasses ignore type hints as well

    Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

    > Type inference and lazy programmers

    The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

    > Exceptions are not covered [like Java]

    I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

    [0] https://github.com/RussBaz/enforce

    [1] https://github.com/agronholm/typeguard

    [2] https://github.com/microsoft/pyright

    [3] https://pydantic-docs.helpmanual.io

    [4] https://github.com/tiangolo/fastapi

    [5] https://github.com/microsoft/pyright/blob/main/docs/configur...

    [6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

  • fastapi

    FastAPI framework, high performance, easy to learn, fast to code, ready for production

    Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

    Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

    > type hints are not binding.

    There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

    It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

    > Type checking is your job after all, ...[and that] requires maintenance.

    There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

    > There is an Any type and it renders everything useless

    I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

    > Duck type compatibility of int and float

    The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

    > Most projects need third-party type hints

    Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

    > Sadly, dataclasses ignore type hints as well

    Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

    > Type inference and lazy programmers

    The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

    > Exceptions are not covered [like Java]

    I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

    [0] https://github.com/RussBaz/enforce

    [1] https://github.com/agronholm/typeguard

    [2] https://github.com/microsoft/pyright

    [3] https://pydantic-docs.helpmanual.io

    [4] https://github.com/tiangolo/fastapi

    [5] https://github.com/microsoft/pyright/blob/main/docs/configur...

    [6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

  • typeshed

    Collection of library stubs for Python, with static types

    https://github.com/python/typeshed also provides community maintained stub packages for packages that are lacking upstream type hints

  • languages-that-compile-to-python

    List of languages that compile to python

    The flawed nature of JS, yet remaining the only one supported by browsers, has indeed created a unique environment where many nice languages have appeared that compile to JS. Besides TypeScript there's Elm, ReasonML, ClojureScript, and many more.

    There are a some competing languages for the Python runtime as well: https://github.com/vindarel/languages-that-compile-to-python

  • urllib3

    Python HTTP library with thread-safe connection pooling, file post support, user friendly, and more.

    (I've chopped it down a bit to emphasise the important bits)

    But then I looked at upstream and I notice they've added type annotations, which do greatly improve things:

    https://github.com/urllib3/urllib3/blob/e16beb210c03c6f5ce4e...

        def _new_conn(self) -> socket.socket:

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts