> I also find it kind of hilarious that type checking isn't built into the standard python interpreter, but you need a separate tool instead.

Agreed, typically you don't add new syntax to a language only to silently ignore it. I think the plan may be to add runtime checking to the Python interpreter later.

> I think the plan may be to add runtime checking to the Python interpreter later.

And slow the run time back down several versions.

I don't think people select Python for it's performance ;)

But the type-checking could be a command line parameter, used only during development.

It already can be used for development, IDEs such as PyCharm perform quite effective live type checking based on type hints.

Note that PyCharm and mypy's semantics differ in some key ways:

https://youtrack.jetbrains.com/issue/PY-54411/Type-checkers-....

https://youtrack.jetbrains.com/issue/PY-24834/Support-strict...

Usually static types allow for better optimizations, but this is python, so the implementation is probably maximally pessimal.

My understanding is that the relationship is a lot more complex than "types = faster code". Types are often necessary for highly efficient code, yes, because the allow you to avoid lots of indirection and just give the hardware the raw numbers and instructions that it wants. But they aren't sufficient - you can't just have types, you also need to guarantee that those types are always the correct ones (i.e. that when I tell you it's an int, it will never be a string). In practice, the performance gains you get from using types are matched by the performance losses from having to validate them.

You can solve this by restricting What's possible significantly (you see this, for example, in RPython and Cython, where static types are used more effectively, but come with significant metaprogramming restrictions). But at that point, you're losing a lot of the value of a dynamic language. One of the big reasons that Typescript works so well here is that it has all sorts of escape hatches, so that you can write mostly correct Typescript code, but if you need to write something completely dynamic, you can always just define the arguments and return types and cast everything else to `any`. This is why, even though Cython exists and is much quicker than Python, it tends to only be used to speed up specific sections of code, with the rest of the codebase being dynamic Python glue.

The other side of this is that there already is a solution to performance issues in dynamic languages, and that's JIT compilation. Javascript is consistently one of the faster languages for lots of web tasks, and that's in no small part due to the significant effort put into optimising V8 and the other JIT runtimes. The best thing about JIT compilation is that you don't need to write the types at all, because the type information can be read at runtime. Theoretically, you could incorporate type hints into the optimisation process, but this probably won't give as much good information as actually running the code and seeing what types pop out.

Of course, the other side of this is to ask what the value of type hints are in the first place. I think a lot of Python developers are used to things like Cython, where types almost exclusively refer to the underlying data formats (i8, i32, u64 etc), but the biggest value to type hints and tools like mypy is not just defining struct layouts, but describing a program's behaviour at a higher level - for example, declaring that a variable can be one of these two types and ensuring that the developer never forgets that. Or defining a closeable resource like a file handle that can't be used after it's been closed. Or making sure that the developer handles each case of an enumeration and doesn't miss anything.

The types that are useful for those sorts of things tend not to be so useful for optimisation purposes, but they are _very_ useful for ensuring that code is semantically correct.

> Agreed, typically you don't add new syntax to a language only to silently ignore it.

The only new syntax here is variable and function annotations and it allows you to put anything into the annotation, so it makes sense the compiler would ignore them. Type hints are one possible usage of such annotations but they are not part of the syntax (because the types are just regular Python objects).

The reason is that the community decided they needed some form of type annotations, but nobody could agree on which ones or how they should work. So some syntax was added just so the parser wouldn't fall over, but the semantics were left to other projects to "let 100 flowers bloom".

This worked about as predictably as you would expect. If you grabbed a random package from pypi, suddenly your choice in typechecker might complain about its API if it wasn't made using the same typechecker as you, so a separate, "standard" choice in typechecking was made called mypy. But they couldn't break older code not using mypy so it's strictly optional.

> so a separate, "standard" choice in typechecking was made called mypy

This distorts reality a bit. Mypy is one of the flowers; Jukka developed the annotation syntax. It got popular enough to become the de facto standard. I would say the strategy worked.

You should try F#. It infers all the types so you get the benefits of type checking without the noise

F# really is a great language. I wish it was used more.

My trouble with this approach is that my brain is not very good at type inference, so I don't really understand what's going on just by reading the code. IDEs can help, but it's still a hassle (esp. in contexts where you don't have IDE - github PRs etc.)

Perhaps it might not make sense to write type hints for your own prototyping code, but the fact that many libraries and stdlib functions are annotated certainly improves my velocity.

Yes! I find this with TypeScript and JavaScript too. Even if I’m just writing a quick script in JS, the fact that most of the libraries I’m using have TS definitions is really useful.

The trick is to focus on the types of (top-level) functions. This way, it can be super concise and machine-readable API documentation.

Regarding the example of the original article, it demonstrates how type hinting doesn't turn a language like Python or JavaScript into Haskell, where everything is neatly typed. Type-wise, it just does not make sense to use the operator + for both addition and concatenation, hence the example function slow_plus does not make sense either.

I admit I have difficulty knowing when I should just use Any and stop trying harder.