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

151–160 of 597 posts

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

#151

Post by the_af »

rglullis wrote: post #143
the_af wrote: post #109

Earlier quoted context omitted.

I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.

Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.

You get me wrong: my coworkers struggle to see the point of testing at all.

Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job.

This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't.

This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though.

> If you/your team want to use a statically typed language, then use one. Python is not it.

This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?

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

#152

Post by TillE »

the_af wrote: post #151
rglullis wrote: post #143

Earlier quoted context omitted.

Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.

You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really…

Your criticism was:

> it just doesn't work cleanly out of the box like in true statically typed languages

So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.

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

#153

Post by simonw »

"You don’t know if there really is a tool in place to check them."

Every project I interact with that uses type hints runs mypy as part of CI - and I can see that they're setup to do that by looking at the CI configuration (which these days is usually done using GitHub Actions).

I wouldn't add type hints to a project without also configuring mypy for it.

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

#154

Post by noitpmeder »

throwaway81523 wrote: post #59
davidhariri wrote: post #37

Earlier quoted context omitted.

Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.

I've found that even when I write code intended to be statically checked from the beginning, mypy often misses stuff. I was enthusiastic about mypy at first and I still use it, but I'm not sure at this point that it is worth it.

I think this is only going to happen in reality if you're doing funky type hacks in the first place. Mypy definitely has rough edges, but it works perfectly in 95% of every codebase I've seen.

Type hints (with mypy) aren't going to save you from becomming a bad programmer. But they _do_ help you become a better one!

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

#155

Post by sevensor »

civilized wrote: post #44
ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

> 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 enforces its runtime types at runtime. 'hello' is a perfectly valid argument to print. Python will raise a TypeError if you try to use it to index a list though.

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

#156

Post by woodruffw »

civilized wrote: post #44
ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

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

> In what reasonable sense can Python be said to "enforce types at runtime" here?

Python is both strongly typed and protocol-typed. In the case of `print(...)`, the protocol is that the received parameter responds to `str(...)` (i.e., has `__str__`).

(What Python isn't is statically typed. But "strong" and "static" are completely different typing dimensions.)

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

#157

Post by sevensor »

simonw wrote: post #153

"You don’t know if there really is a tool in place to check them." Every project I interact with that uses type hints runs mypy as part of CI - and I can see that they're setup to do that by looking at the CI configuration (which these days is usually done using GitHub Actions). I wouldn't add type hints to a project without also configuring mypy for it.

Precisely. We don't merge unless the result passes mypy.

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

#158

Post by the_af »

AnimalMuppet wrote: post #145
the_af wrote: post #140

Earlier quoted context omitted.

I find this level of nitpicking puzzling. You know what I meant and what error I was clarifying for the comment I was replying to. Yet you went out of your way to point all sorts of irrelevant mistakes in my post, when the gist of it was right. Do you feel it was more important to correct me on these trivial things, or was my reply more or less correct when fixing the conceptual error in this sentence?: > "In what re…

1. You might need to re-read the site guidelines about assuming good faith. 2. Your last two sentences were, I think, not needed for the point you were making. They were also somewhere between gross generalizations and flat-out wrong, and felt like a gratuitous slam on a language that wasn't even the topic. I thought that deserved a response, even if it wasn't your main point. 3. I may assume that you know C. I don't…

> "They were also somewhere between gross generalizations"

Pointless correction. Gross generalizations are not wrong in this particular situation, which is not meant to teach anyone C.

Let me try again.

Do you think that your correction was more important than helping the poster of this comment correct their conceptual mistake?

> "In what reasonable sense can Python be said to "enforce types at runtime" here?"

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

#159

Post by forrestthewoods »

lifewallet_dev wrote: post #133
forrestthewoods wrote: post #22

Earlier quoted context omitted.

> If you want types, use something else other than Python. Python is still strongly typed. Me: what type does this argument need to be? Python: you have to figure that out Me: I just pass whatever I want? Python: Oh no. Usually only a single specific type is supported. But you have to guess what it is. Me: what if I get it wrong? Python: the program crashes at runtime

You don't understand what "strongly typed" means... I give you a hint, `"1" == 1` is a type error in Python but "okay" in JavaScript because this one is "weakly typed", you're confusing "dynamic typing vs static typing" with "strongly typed vs weakly typed".

Python is a strongly, dynamically typed language. Most Python type errors could be caught by a static analyzer. If Pythons type hint system wasn’t a disappointment it would help more people catch more bugs when they’re written. Instead Python endlessly throws exceptions at runtime because a programmer got their types wrong.

Thanks for the hint.

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

#160

Post by [deleted] »

ledauphin wrote: post #76
civilized wrote: post #63

Earlier quoted context omitted.

It seems that your point boils down to "Python enforces types at runtime if you define 'enforce types at runtime' not to include 'enforcing that data you declare to be of a certain type actually is of that type'". Am I the only one baffled by this way of thinking?

Python does and always has enforced types at runtime. This is called duck-typing. If you're not familiar with the concept of strong+dynamic, it is easy to see how this could be confusing. This may help. https://stackoverflow.com/questions/2351190/static-dynamic-v... Static type annotations by definition are not enforced at runtime. This has been true of every language that has ever used static typing, including C, C+…

[deleted]
Post reply on HN