[wraptile]

The problem is that people try to turn type hints into static types. I got rid of mypy from all of my projects as it provided no value and just created this constant battle of "making it work" - a collosal time waste. As this blog illustrates - so much extra effort for something so trivial and unimportant - this whole shebang goes against the spirit of Python.

In general I've yet to see what these type check systems (be it mypy, pyright or any other) offer over proper tests. Type hints are there for developers not the machine.

[ameminator]

I'm going to hard disagree with you here. Type hints are a key tool in working on a large Python project in a large team. Tests are, of course, necessary. But type hints allow Python (and all its benefits) to be used in industrial environments where it otherwise would be intractable.

[hansvm]

It sounded to me like they agree with you -- type hints are valuable -- just with the caveat that satisfying the tooling around them is a waste of time when most of the benefits can be had with minimal effort writing type hints explicitly for the consumption of other developers.

E.g., when I write numerical python code I'll often just use a string like `"(n_items, n_dims)"` as the type hint, or if the only salient detail of a signature is that some dimensions match I might even write something as simple as `foo(bar: "(a, b)", baz: "(b, c)")`. Ofttimes that's the only data a developer really cares about in that programming context, so a more complete type hint (one designed for mypy and the rest of the tooling) would just take longer to read and understand.

[wraptile]

exactly! What I meant is that returns on mypy compliance investments are extremely poor. For most projects it makes no sense to invest so much time playing this "hack this hint" games but for big projects every single digit% improvement counts.

Most projects don't need it and I can't help but facepalm when I see small projects have half of their commits describing typing compliance battles just because mypy came with "yet another python project boilerplate" or pressure from the industry.

[lmm]

> In general I've yet to see what these type check systems (be it mypy, pyright or any other) offer over proper tests. Type hints are there for developers not the machine.

In a language with proper first-class typing, the advantage is that they're included in your automated refactoring rather than needing manual updates. But yeah I've never found optional type systems to be any use.

[BerislavLopac]

> people try to turn type hints into static types

The only way for type hints not to be static types is to not run the checker before deploying.

Static typing means that the types of variables and their values are statically checked (hence the name) before the execution; in most statically typed languages that happens at compile time. There is no static check at runtime, and it's perfectly possible to send an incorrect type to a dynamically loaded library even in compiled languages (which usually, but not necessarily, results in crashing he program).

[toomanydoubts]

Python sucks, type hints border idiocy. If you can't trust the hint to actually be correct and still have to check for yourself, they become pointless.

If you want to see where static typing really shines, try writing some Haskell. It's an absolute delight.

[tehnub]

What do you mean you can't trust them? If you write a type hint in your code and then run mypy on it, it will tell you whether the type is being violated. And, PyCharm has a type checker built in that lets you know as you're coding.

[lmm]

> If you write a type hint in your code and then run mypy on it, it will tell you whether the type is being violated.

Only if the type hints for all the libraries you use are correct (and in practice they're not).

[mark_l_watson]

Ah, thanks. I think I am going to give type hints another try.