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

191–200 of 597 posts

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

#191

Post by rglullis »

the_af wrote: post #177
rglullis wrote: post #168

Earlier quoted context omitted.

> How else will the language improve then? That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. > We can improve the tooling and train the team with better practices though. "Better practices" are what makes you team more productive, not just blindly copying what…

> That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. Let me give you a twofold answer to this. 1. I do think statically typed languages are generally better than dynamic languages for most use cases (with a few exceptions). I don't expect to convince you or anyo…

> generally better than dynamic languages for most use cases

Shouldn't then the exercise be to figure out if these use cases are applicable to your situation?

What is your team and company optimizing for?

> How else will languages improve if nobody is working on addressing their pain points?

"See, at my work we need to travel between two islands as fast and cheap as possible. My team is used to high-speed motorboats, but my experience tells me that hydroplanes are faster. I tried putting wings on my motorboats, but it still wasn't as fast. No, we can not buy hydroplanes. No, my team is not licensed to fly. But if no one acknowledges that motorboats are slower, how will they ever be as fast as a hydroplane?

And no, I haven't really looked into the fuel costs of planes vs boats..."

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

#192

Post by ModernMech »

hermitdev wrote: post #88
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…

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature. In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic t…

> "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime.

I read the sentence as

  "you don't know the real types of variable at [the start of] runtime"
as opposed to

  "you don't know the real types of variable *during* runtimes"
So I understood the author to mean what you said. Could have been clearer you're right.

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

#193

Post by linsomniac »

np_tedious wrote: post #186
linsomniac wrote: post #180

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…

> I'm not even using mypy often, if ever. Hopefully your CI does?

Not yet, but that might be coming. I have one personal project set up to run mypy as a pre-commit, but I'm not (quite) ready to force that on my coworkers.

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

#194

Post by Jach »

cardanome wrote: post #120
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…

> 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! So PHP is not a dynamically typed programming language according to you? It enforces type hints at runtime just fine. There is nothing in the definition of dynamically typed languages that says they can…

Was going to say the same for some implementations of Common Lisp, notably SBCL, which by default treats type declarations additionally as assertions. Subject to limitations it can use declared types and infer more types at compile time to produce more optimal assembly and give warnings if it detects type errors, or interestingly warnings if it has a chance to use e.g. a fast assembly add on a fixed sized int if you help narrow its inferred type with an explicit declaration one way or another. But unless it can prove a type always holds, it will also by default check declared types at runtime.

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

#195

Post by [deleted] »

zmgsabst wrote: post #114
ljojiasdf wrote: post #99

Earlier quoted context omitted.

Can you re-read please? https://peps.python.org/pep-0544/#:~:text=Structural%20subty... . > substituted-for class to be defined as a protocol. ... which is false > Similarly, the heading on the dictionary says “for a fixed set of keys” — but what if I want a dynamic heterodox dict? Eg, unpacking JSON. You can quite obviously decode to recursive types (e.g. using pydantic), not sure what the problem is.

Your link appears not to work (for me) — can you cite what you believe I have incorrect? This section seems to agree with me, where it explains why normal classes can’t be subclassed to protocols: > Now, C is a subtype of Proto, and Proto is a subtype of Base. But C cannot be a subtype of Base (since the latter is not a protocol). This situation would be really weird. In addition, there is an ambiguity about whether…

[deleted]

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

#196

Post by oefrha »

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.

MyPy isn’t the only checker of course, there’s also Microsoft’s Pyright, among others. Pyright is fast and natively integrated in Microsoft’s Pylance VSCode extension, so these days I use Pyright’s type checking in real time even when I can’t be bothered to set up MyPy (no difficult, just not important for, say, https://github.com/microsoft/pyright

https://marketplace.visualstudio.com/items?itemName=ms-pytho...

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

#197

Post by gkhartman »

linsomniac wrote: post #180

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…

I use them for the same reason. I've started sprinkling them into projects where I can. Other devs on the team seem to like seeing them, but have higher inertia when it comes to writing them.

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

#198

Post by folkrav »

whimsicalism wrote: post #189
nas wrote: post #170

Earlier quoted context omitted.

I've found that it's pretty easy to slowly enable mypy checking. You can mark modules with "type:ignore" to make mypy ignore them. Then, you can move to marking individual statements with "type:ignore". Finally, you can start marking modules with "mypy: disallow-any-generics" at the top. That requires that functions are annotated with types. In a large code base, our team has found type annotations and mypy to be qui…

I disagree with your last line, especially for Optional (Union in python is basically useless IMO).

Isn't `Optional[T]` just sugar for `Union[T, None]`?

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

#199

Post by comex »

ledauphin wrote: post #129
the_af wrote: post #101

Earlier quoted context omitted.

> Yes, it is possible to annotate types in Python incorrectly. It's possible to do this in all other languages that allow type-unsafe behavior (whether natively or via reflection, etc). This may be less common in some languages than in others, but it is fundamentally possible in the vast majority of languages that perform static typing, because those types are fundamentally enforced at analysis time, not runtime. It…

I think your (and the article's) argument could be summarized as "static type annotations without automated enforcement by actually running a type checker considered harmful". Since this argument is not meaningfully different from "comments that are lies considered harmful", it seems fair to expect reasonable people to dismiss it as uninteresting.

It is meaningfully different because, as the article says, comments are known to not be machine verified and thus to potentially be wrong. With type hints, they’re usually verified, but not always, so you’re more likely to trust them and get a nasty surprise when they turn out to be wrong.

However, there are other aspects to the article’s argument, such as the fact that it’s easy to end up with type annotations going silently unenforced even if you do run the checker.

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

#200

Post by the_af »

rglullis wrote: post #191
the_af wrote: post #177

Earlier quoted context omitted.

> That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. Let me give you a twofold answer to this. 1. I do think statically typed languages are generally better than dynamic languages for most use cases (with a few exceptions). I don't expect to convince you or anyo…

> generally better than dynamic languages for most use cases Shouldn't then the exercise be to figure out if these use cases are applicable to your situation? What is your team and company optimizing for? > How else will languages improve if nobody is working on addressing their pain points? "See, at my work we need to travel between two islands as fast and cheap as possible. My team is used to high-speed motorboats,…

Your "islands" anecdote is amusing, if a bit condescending. Do you honestly think it fairly addresses the very direct question I asked you?

Also, do you honestly expect me to detail what my team and company is optimizing for here? What for? What does it have to do with Python type hinting?

Post reply on HN