Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python’s “type hints” are a bit of a disappointment to me

uninformativ.de

Post reply on HN
Print view View original

331–340 of 597 posts

Re: Python’s “type hints” are a bit of a disappointment to me

#331

Post by fer »

linsomniac wrote: post #175
civilized wrote: post #44

Earlier quoted context omitted.

> not-very-educated thoughts on gradual typing This seems like an inaccurate and condescending put-down. What is the definition of "educated" in this context? Is there a book or generally well-known resource? The author is clearly thoughtful and curious. Near the top of the post he says "what I’m hoping for is that someone will come along and tell me that I got it all wrong. “When you do it as follows, the system wor…

Python can't be said to enforce types at runtime. AFAIK, it doesn't say that. In fact, the original article starts off with "I'm expecting to be able to run a static analyzer", then it goes on to say "This isn't caught at runtime". Yes, but is it caught at static analyzer run? Yes, I typed it into vi and ran mypy on it and it said "error: Incompatible types in assignment (expression has type "str", variable has type…

> Python can't be said to enforce types at runtime.

It does: in form of TypeError exceptions. It doesn't enforce type hints, sure, but that's why they're called hints and not declarations.

Re: Python’s “type hints” are a bit of a disappointment to me

#332

Post by DangitBobby »

mikewhy wrote: post #273
MBCook wrote: post #252

Earlier quoted context omitted.

noImplicitAny is a very common config option that helps catch a ton of bugs. I wouldn’t use TS without it.

noImplicitAny is different than what's being discussed (I think). Returning something typed as `any` in a function that has a different return type is totally fine: it's not implicit (you've cast it to any), and it passes (you're saying the type is literally anything after all). There are lint rules to avoid typing as `any`.

There are "no explicit any" linting rules as well, which are a must.

Re: Python’s “type hints” are a bit of a disappointment to me

#333

Post by nwatson »

PyCharm with type-hinting and "inspections" (which include pseudo-static analysis for appropriate type use) have only added to the awesomeness of great code navigation, refactoring, auto-completion, code-formatting, etc.

If you're going to have type-hints, you need pseudo-static analysis.

Re: Python’s “type hints” are a bit of a disappointment to me

#334

Post by nyuszika7h »

> and in new versions of your type checker, you have to make sure that they didn’t change their meaning and that they didn’t introduce new flags that you really, really should use.

That's what the --strict flag is for, which the author even quietly uses in a later example without explaining it. Though it may be too noisy to immediately turn it on in some projects.

As for the example of getting something returned from the network that has a mismatching type, there's no way mypy could guess that. You'd have to add an explicit `isinstance(foo, int)` check or use a runtime type checker.

The author does have a point that people might simply use wrong type hints if they don't have a proper type checker set up though. I've seen so much code with `any` instead of `Any`, `[foo]` instead of `list[foo]`, etc. as type hints. Using something like pre-commit and/or editor plugins to run mypy automatically while editing is probably the best. But it's true that even then, without --strict or equivalent, you can too easily satisfy the type checker by simply annotating something as a `dict` or `list`, without explicitly using `Any`.

Still, I don't think this means we shouldn't use type hints at all. It could definitely be more beginner-friendly, but most of the mentioned issues can be addressed with proper configuration.

Re: Python’s “type hints” are a bit of a disappointment to me

#336

Post by ohmahjong »

folkrav wrote: post #204
Bedon292 wrote: post #176

Earlier quoted context omitted.

We use pre-commit and you can't even commit until it passes mypy. It can be a bit frustrating sometimes, but overall it has saved us from a lot of issues.

I like the validation scripts being available in a repo so I can run them locally before pushing to CI, but I also often use WIP commits and quick fixups and then rebase before opening the PR, so pre-commit hooks are really annoying to my workflow. I more often than not just do `git commit --no-verify` or simply delete the git hook in `.git`, then just run it myself before pushing. Anyway CI will catch it, so I don't…

This has been my experience as well, as someone who added a pre-commit hook (black and mypy) to a repo in lieu of adding it to CI (it was a while ago). I came back to the team a year later to find that everyone had simply disabled the hook, and forgone typing/formatting entirely. A day or two of fixing formatting, type hints and linting errors later, the CI pipeline had a new step enforcing all three :)

Re: Python’s “type hints” are a bit of a disappointment to me

#337

Post by hummingn3rd »

kortex wrote: post #326

This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling. My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy p…

I was curious of seeing if pydantic was mentioned, thanks! We use most of the same tooling as you, I'm always interested in improving our tooling, would you be willing to share your mypy plug-ins names or maybe most useful tools for inspiration?

Re: Python’s “type hints” are a bit of a disappointment to me

#338

Post by eyelidlessness »

strogonoff wrote: post #318
eyelidlessness wrote: post #165

Earlier quoted context omitted.

> However, even in Typescript it is nontrivial to _annotate_ these complex types The only one which stands out to me as non-trivial in TypeScript is thrown exceptions… and even then only because you can only type them in a catch clause, and only with unknown, and they’re invisible to callers. But then this is why people who would care for checked exceptions quite reasonably just use something like a Result type. But…

I had to come back to Python after working with TypeScript for a while. After going from Python 2.x to TypeScript and being very impressed with static typing, I didn’t want to go back to untyped so I had to get up to speed with the ecosystem. My findings: — Consider using Pydantic (either its drop-in dataclasses replacement, or its models). It has issues and documentation is lacking in places, but in many use cases i…

Thank you for so much detailed advice! I’m sure this will be valuable to reference as I dive in

Re: Python’s “type hints” are a bit of a disappointment to me

#339

Post by t43562 »

Correctness in Python is all about unit tests - if you don't bother with them then you're playing with fire (and of course I often "play with fire").

Type hints .... well they help the IDE to autocomplete which is great. They also help you to get the order of parameters in a function/method call correct which is useful if the parameters aren't all the same type!

I converted a medium sized project to type hinting once. The original author wrote no tests and obviously didn't design it to be testable so I was looking for some small way to make it less horrendously unmaintainable. Every test run of the source took hours and there would be some trivial syntax error or whatever right at the end.

Type hints weren't so difficult and I hoped that they would "staunch the bleeding" while I tried to get it into testable shape. In this case they did almost nothing - didn't help me stop a single bug - probably because most types were "str" but that's not the fault of the hinting system as an idea, right? It's just an unprofitable load of work in particular situations.

Static typing fans are always going to be disappointed by Python and it's great because there are other languages for them. For the rest of us we can use them where it turns out to be profitable to us.

Unit tests are, however, by 1000x, more important.

Re: Python’s “type hints” are a bit of a disappointment to me

#340

Post by arinlen »

t43562 wrote: post #339

Correctness in Python is all about unit tests - if you don't bother with them then you're playing with fire (and of course I often "play with fire"). Type hints .... well they help the IDE to autocomplete which is great. They also help you to get the order of parameters in a function/method call correct which is useful if the parameters aren't all the same type! I converted a medium sized project to type hinting once…

> Correctness in Python is all about unit tests - if you don't bother with them then you're playing with fire (and of course I often "play with fire").

But Python does support type hints, and tools like MyPy do use those type hints to evaluate correctness. It seems to me that Python's type hints are indeed Python's way to check for correctness.

Also, unit tests don't verify correctness. They only serve to check whatever small set of ad-hoc invariant developers put up.

Post reply on HN