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

Python type hints may not be not for me in practice

utcc.utoronto.ca

Post reply on HN
Print view View original

151–160 of 209 posts

Re: Python type hints may not be not for me in practice

#151

Post by dataflow »

slowking2 wrote: post #81
satvikpendem wrote: post #49

Earlier quoted context omitted.

It's not about the bugs, it's about designing the layout of the program in types first (ie, laying out all of the data structures required) such that the actual coding of the functionality is fairly trivial. This is known as type driven development: https://blog.ploeh.dk/2015/08/10/type-driven-development/

At work, I find type hints useful as basically enforced documentation and as a weak sort of test, but few type systems offer decent basic support for the sort of things you would need to do type driven programming in scientific/numerical work. Things like making sure matrices have compatible dimensions, handling units, and constraining the range of a numerical variable would be a solid minimum. I've read that F# has…

If x is of type T, what type do you want (x - x) to be?

Re: Python type hints may not be not for me in practice

#152

Post by lmm »

junyjujfjf wrote: post #82
tasn wrote: post #21

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

> The Python type system is pretty bad Coming from the perspective of a religious python hater, their type hints are better than what you give credit for: Supports generics, nominative, structural, unions, bottom type, and literals. What is missing is mainstream adoption in libraries which is a matter of time.

Optional typing is always a castle built on sand. I don't see Python typing ever becoming reliable, because there's no way you can retrofit the entire ecosystem that thoroughly.

Re: Python type hints may not be not for me in practice

#153

Post by shakna »

slowking2 wrote: post #81
satvikpendem wrote: post #49

Earlier quoted context omitted.

It's not about the bugs, it's about designing the layout of the program in types first (ie, laying out all of the data structures required) such that the actual coding of the functionality is fairly trivial. This is known as type driven development: https://blog.ploeh.dk/2015/08/10/type-driven-development/

At work, I find type hints useful as basically enforced documentation and as a weak sort of test, but few type systems offer decent basic support for the sort of things you would need to do type driven programming in scientific/numerical work. Things like making sure matrices have compatible dimensions, handling units, and constraining the range of a numerical variable would be a solid minimum. I've read that F# has…

Crystal certainly supports that kind of typing, and being able to restrict bounds based on dynamic elements recently landed in GCC making it simple in plain C as well.

Re: Python type hints may not be not for me in practice

#154

Post by dataflow »

otherme123 wrote: post #75
rty32 wrote: post #62

Earlier quoted context omitted.

> The other side is those people who do not find those kind of bugs annoying Anecdotally, I find these are the same people who work less effectively and efficiently. At my company, I know people who mainly use Notepad++ for editing code when VSCode (or another IDE) is readily available, who use print over debuggers, who don't get frustrated by runtime errors that could be caught in IDEs, and who opt out of using codi…

>these people don't push code out as fast they could. Well, one of my coworkers pushes code quite fast, and also he is the one who get rejected more often because he keep adding .tmp, .pyc and even .env files to his commits. I guess "git add asterisk" is faster, and thus more efficient, than adding files slowly or taking time to edit gitignore. Not so long ago I read a history here in HN about a guy that first coded…

> Not so long ago I read a history here in HN about a guy that first coded in his head, then wrote everything in paper, and finally coded in a computer. It compiled without errors. Slow pusher? Inefficient?

I've read and heard stories about these folks too, apparently this was more common decades ago.

To be clear, I don't think I could pull it off with any language. It's quite impressive and admirable to get things right on the first try.

Having said that, the thing is, languages were a lot simpler back then too. I'm not convinced this is realistically even possible with today's languages unless you constrain yourself to some overly restrictive subset. Like try this with C++, and I would be shocked if you can write nontrivial programs without getting compiler errors. Like to give a trivial example, every time I write my own iterator class for a container, I miss something when I hit compile: like either a comparison operator, or subtraction, or conversion to const iterator, or post-decrement, or subscript, or some member typedef. Or try it with python, and I bet you'll call .get() on something and then forget to check for null somewhere.

I would love to be proven wrong though. If anyone knows of someone who does this with a modern language, please share.

Re: Python type hints may not be not for me in practice

#155

Post by liontwist »

junyjujfjf wrote: post #118
liontwist wrote: post #94

Earlier quoted context omitted.

This distinction makes no sense. Can you explain why types would be more relevant?

Actually I don't think types are relevant here. People are choosing based on other weighted factors like toolchain, ecosystem, products, and culture.

Are you a bot?

Re: Python type hints may not be not for me in practice

#156

Post by slowking2 »

Chris_Newton wrote: post #112
slowking2 wrote: post #81

Earlier quoted context omitted.

At work, I find type hints useful as basically enforced documentation and as a weak sort of test, but few type systems offer decent basic support for the sort of things you would need to do type driven programming in scientific/numerical work. Things like making sure matrices have compatible dimensions, handling units, and constraining the range of a numerical variable would be a solid minimum. I've read that F# has…

I suspect C++ still comes the closest to what you’re asking for today, at least among mainstream programming languages. Matrix dimensions are certainly doable, for example, because templates representing mathematical types like matrices and vectors can be parametrised by integers defining their dimension(s) as well as the type of an individual element. You can also use template wizardry to write libraries like mp-uni…

I'd be happy for just ranges on floats being quick and easy to specify even if the checking is at runtime (which it seems like it almost will have to be). I can imagine how to attach precision error/metadata when I need it with custom types as long as operator overloading is supported. I think similarly for specialized matrices, normal user defined types and operator overloading gets tolerably far. Although I can understand how different languages may be better or worse at it. Multiple dispatch might be more convenient than single dispatch, operator overloading is way more convenient than not having operator overloading, etc.

A lot of my frustration it is that the ergonomics of these things tend to be not great even when they are available. Or the different pieces (units, shape checking, ranges) don't necessarily compose together easily because they end up as 3 separate libraries or something.

Re: Python type hints may not be not for me in practice

#158

Post by slowking2 »

dataflow wrote: post #151
slowking2 wrote: post #81

Earlier quoted context omitted.

At work, I find type hints useful as basically enforced documentation and as a weak sort of test, but few type systems offer decent basic support for the sort of things you would need to do type driven programming in scientific/numerical work. Things like making sure matrices have compatible dimensions, handling units, and constraining the range of a numerical variable would be a solid minimum. I've read that F# has…

If x is of type T, what type do you want (x - x) to be?

That's a hard one because it depends on what sort of details you let into types and maybe even on the specific type T. Not saying what I'm asking for is easy! Units and shape would be preserved in all cases I can think of. But with subranges (x - x) may have a super-type of x... or if the type system is very clever the type of (x - x) maybe be narrowed to a value :p

And then there's a subtlety where units might be preserved, but x may be "absolute" where as (x - x) is relative and you can do operations with relative units you can't with absolute units and vice versa. Like the difference between x being a position on a map and delta_x being movement from a position. You can subtract two positions on a map in a standard mathematical sense but not add them.

Re: Python type hints may not be not for me in practice

#159

Post by sa-code »

joeyagreco wrote: post #77

> After the code has stabilized I can probably go back to write type hints [...] but I'm not sure that this would provide very much value. I think most developers who revisit their projects 6+ months later would disagree with the second part of this statement. My typical flow for "quick scripts" is: on first pass I'll add basic type hints (typing ":str" after a func param takes .2 seconds) for more complex data struc…

And when I inherit a code base with no type hints asking an LLM to have a go at adding type hints also takes no time at all

Re: Python type hints may not be not for me in practice

#160

Post by Hackbraten »

maleldil wrote: post #85
Hackbraten wrote: post #4

> yet another Python thing I'd have to try to keep in my mind despite it being months since I used them last. Typing hints are also a moving target: they have changed, sometimes significantly, on every minor Python release since they came to be. The `Optional` type came and went (being replaced by the new Union syntax.) Type classes are usually born in the `typing` module, then some of them get moved to `collections`…

The old stuff never stopped working, though. You can still use Optional, Union, TypeAlias, and import collection protocols from typing. You don't have to migrate if you don't want to. They're not even deprecated.

I encourage you to open the `typing` documentation [0] and search for the word `deprecated`.

Spoiler alert: the search result will be three-figure.

Some of the results are already scheduled for removal.

[0]: https://docs.python.org/3/library/typing.html

Post reply on HN