Hacker News Reader

Comment by the_af | Hacker News Reader

I can only speak about my own experience:

Most people I know writing Python don't use type hints because they are too much of a hurdle for very little payoff. The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. The type hints themselves are of dubious use.

As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful.

View on HN

> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand.

I use mypy daily on big codebases, it is fine, not fast, but fine.

> The type hints themselves are of dubious use.

They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing different. python with a static type checker running in strict mode is not fundementally different from Java's static type checking.

> As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful.

What do they lack that would make them useful?

> The same as in literally every other language with static typing

No, obviously not the same, otherwise I wouldn't be complaining. They are not even on par with Typescript, which I'm not a fan of either.

> [type hints] tell you when you make type errors

Not according to other comments I seem to be getting here. Other people are arguing type hints are not primarily for checking, but a form of notation for documentation. Seems wasteful, and I wish the Python community and tooling decided instead that they are for actually checking them.

> What do they lack that would make them useful?

Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so.

I haven't found mypy to fill these requirements. It's so bad I cannot convince my coworkers to make the effort to write more type hints.

> No, obviously not the same, otherwise I wouldn't be complaining.

What is the difference?

> They are not even on par with Typescript, which I'm not a fan of either.

Go is not on par with Typescript or Python, I still don't think it is okay for people to just say fuckit and `interface{}` it all and it is still shit to work with code that does use `interface{}`. At least Python with mypy has null safety, something that Java and Go does not have. There are some places it is worse than other statically typed languages, others where it is better.

> Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so.

It is mypy. What actual type errors does mypy not catch that you want it to catch? Why can't you use it in the build pipeline? I do it every day, it catches all the errors it should. The one complaint I can maybe see is the duct type compatibility complaint, and it is not really something that comes up that often for me, and definitely not something I would say invalidates the whole concept.

> What is the difference?

I'm not going to repeat myself, I already told you.

I find mypy slow, unsatisfying, inconsistent, and it fails to catch many type errors. No, I'm not going to go look in my work laptop to give you an example.

> There are some places it is worse than other statically typed languages, others where it is better.

In most places it is way worse, and I'll find it very hard to find common ground with anyone who disagrees on this.

Feel free to disagree, but I don't find this conversation useful.

How big is your code base? I’ve worked with really large auto generated codes and mypy never took more than a minute or two to run. On more normal sized code bases it’s just a few seconds. It’s also incremental so subsequent runs are faster.

Compare that to a c++ project where it’s not unusual to have 10, 15, 30 min build times.

Or even worse, the time to wait for discovering the problem runtime in prod.

The type hints also help in IDE navigation, where there is zero time to wait, pycharm can go to definition or find references in under a second.

Better code completion and documentation in you editor is another great feature of type hinting

Have you looked at the tools recently? LSP + Pyright is very fast and plugins exist for many editors. Or maybe it's slow on larger codebases or very large files? I don't have that broad an experience yet, but so far it's been very good.

Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.

mypy is quite fast at the command line. certainly fast enough for CI usage, where speed is generally less critical than in an IDE.

Not my experience!

What speed are you looking for in your CI pipline that you are not getting from mypy? Perhaps you are working on a much larger codebase than I am but the app I use it in takes under a minute. And all the unit tests take longer to run.

A 25k LOC Django project - takes 15-20 minutes to run mypy... Unit tests take about 3 minutes.

That's locally on a fast (ish) laptop. GH CI takes 10 minutes to run tests, so I'm a little hesitant to see how long mypy takes to run.

Use "dmypy", it is fast.

pyright is a command line program https://github.com/microsoft/pyright

in my experience it's a far better type checker than mypy, which tends to silently not check things without you ever realising

Thanks for the suggestion! I didn't know this checker existed. Will definitely try it.

Reply on news.ycombinator.com