> mypy is the static type checker that is the most popular (28.3k repositories, 1.9k packages), if you are using other type checkers then congrats, you will just be the CoffeeScript/Reason user of the JS world, refusing to believe that TypeScript won the mindshare

Not really. TypeScript is a JS superset (and TypeScript tooling works with unadorned JS, too), but Coffee script/Reason are incompatible languages that happen to compile to JS and have static typing. All of the Python typecheckers are more like TypeScript, except that even the type annotations and much of the type system is also standardized as part of the core language. You can literally use any of them on the same code base, and get largely the same results (some will catch some type errors that others miss, some will flag some correct code as possibly erroneous that others would leave alone, but the differences tend to be minor.)

Pytype (Google) pyre (facebook) and pyright (microsoft) all have more institutional backing than mypy. They aren't going away anytime soon.

Otoh, development of all the major type checkers is fairly collaborative. Mypy usually gets features first, but not always.

Why not just adopt one into the standard library, seems like a very obvious battery you'd want to include.

They have different goals. Pytype does inference, which allows easier bootstrapping. Pyre is fast and supports some nonstandard control flow and taint flow stuff. Pyright supports partial validation for syntactically broken files, for use as part of an ide.

> Why not just adopt one into the standard library, seems like a very obvious battery you'd want to include.

Instead, the approach seems to be adopting a standardized system of type annotations into the standard library. While a typechecker may expose a library interface, it's main use is as an executable tool, not a library (unlike annotations themselves), so it's not super critical to have one in the standard library. It might be convenient to have it in the standard distribution, but as a practical matter it's not like there is a problem getting at least one of them that does a suitable job with standard type annotations anywhere you can get Python.

Check out the typing module[1] from the Python standard library. A lot of it was adopted directly from Mypy.

[1] https://docs.python.org/3/library/typing.html

> what does async vs blocking even mean in this context? all languages have the same problem, just use the libraries that are non-blocking.

Maybe Node.js? Although it does have some sync function to do io, most of them are still unblocking, and the ecosystem is unblocking by default too. It is harder to find a blocking library than finding a non-blocking ones.

> * Python 2 is dead.

Officially yes, but in terms of actual use? Not really. Plenty of legacy codebases are still around that don't have the resources to upgrade.

Async vs blocking functions aren't a thing in Erlang and Elixir because everything (almost) is non-blocking.