Hacker News Reader

Comment by wronglyprepaid | Hacker News Reader

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

View on HN

> 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

Reply on news.ycombinator.com