mypyc VS typeguard

That would be interesting! You might already be aware. But there's mypyc[0], which is an AOT compiler for Python code with type hints (that, IIRC, mypy uses to compile itself into a native extension).

Wanted to give you a head-start on the lit-review for your students I guess :)

[0] https://github.com/mypyc/mypyc

https://github.com/mypyc/mypyc

> Mypyc compiles Python modules to C extensions. It uses standard Python type hints to generate fast code. Mypyc uses mypy to perform type checking and type inference.

> Mypyc can compile anything from one module to an entire codebase. The mypy project has been using mypyc to compile mypy since 2019, giving it a 4x performance boost over regular Python.

I have not experience a 4x boost, rather between 1.5x and 2x. I guess it depends on the code.

Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an iteration time but killer guarantees, you end up with committees. Python not falling into either of these traps should be understood as nothing short of magic in emergence.

I only recently discovered that python's reference typechecker, mypy, has a small side project for typed python to emit C [1], written entirely in python. Nowadays with python's rich specializer ecosystem (LLVM, CUDA, and just generally vectorized math), the value of writing a small program in anything else diminishes quickly.

Imagine reading the C++wg release notes in the same mood that you would the python release notes.

[1] https://github.com/mypyc/mypyc

> Note that the mypyc issue tracker lives in this repository! Please don't file mypyc issues in the mypy issue tracker.

See https://github.com/mypyc/mypyc/blob/master/show_me_the_code....

And mypyc https://github.com/mypyc/mypyc

More recent approaches include mypyc which is (on the tin) quite close to what you describe, and taichi that lives in between.

Have you encountered mypyc?

https://github.com/mypyc/mypyc

> Mypyc compiles Python modules to C extensions. It uses standard Python type hints to generate fast code. Mypyc uses mypy to perform type checking and type inference.

Regarding the large execution time mentioned in your article, I discovered (mypyc)[https://github.com/mypyc/mypyc] on this subreddit in a post from the black formatter team https://www.reddit.com/r/Python/comments/v2009i/im_that_person_who_got_black_compiled_with_mypyc/?utm_medium=android_app&utm_source=share

As other folks have commented, type hints are now a big deal. For static typing the best checker is pyright. For runtime checking there is typeguard and beartype. These can be integrated with array libraries through jaxtyping. (Which also works for PyTorch/numpy/etc., despite the name.)

I got good use of the run-time type checking of typeguard [0] when I recently invoked it via its pytest plugin [2]. For all code visited in the test suite, you get a failing test whenever an actual type differs from an annotated type.

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

[1]: https://typeguard.readthedocs.io/en/latest/userguide.html#us...

But you can use a library like typeguard to get runtime typechecking. Or run mypy over the code to get static typechecking.

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...

Personally I find working around mypy's quirks to be more effort than it's worth, so to offer another option: typeguard or beartype can be used to perform run-time type checking.

Never checked? They're statically checked.

Also, tooling like https://pydantic-docs.helpmanual.io/ can do runtime checking for important parts of your app or you can add use this https://github.com/agronholm/typeguard to enforce all types at runtime (although I haven't measured the performance impact, probably something to do in a separate environment than production?).

typeguard