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

81–90 of 209 posts

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

#81

Post by slowking2 »

satvikpendem wrote: post #49
belorn wrote: post #37

Earlier quoted context omitted.

Looking at that blog post, I find it illustrative in how people who like strong types and people who dislike strong types are addressing different form of bugs. If the main types of issues comes from bugs like 1 + "2" == 12" , then strong types is a big help. It also enables many developers who spend the majority of time in a programming editor to quickly get automatic help with such bugs. The other side is those peo…

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 units, Ada and Pascal have ranges as types (my understanding is these are runtime enforced mostly), Rust will land const generics that might be useful for matrix type stuff some time soon. Does any language support all 3 of these things well together? Do you basically need fully dependent types for this?

Obviously, with discipline you can work to enforce all these things at runtime, but I'd like it if there was a language that made all 3 of these things straightforward.

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

#82

Post by junyjujfjf »

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.

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

#83

Post by hbrn »

dinosaurdynasty wrote: post #69
hbrn wrote: post #63

Earlier quoted context omitted.

> Writing software without types lets you go at full speed. Full speed towards the cliff. Isn't it strange that back when Python (or Ruby) didn't even have type hints (not type checkers, type hints!), it would easily outperform pretty much every heavily typed language? Somehow when types weren't an option we weren't going towards the cliff, but now that they are, not using them means jumping off a cliff? Something do…

It's because the nature of typing has changed drastically over the last decade or so, in well known languages, going from C++/Java's `FancyObject *fancyObject = new FancyObject()` (which was definitely annoying to type, and was seen as a way to "tell the compiler how to arrange memory" as opposed to "how do we ensure constraints hold?") to modern TypeScript, where large well-typed programs can be written with barely…

Large programs are harder to maintain because people don't have the balls to break them into smaller ones with proper boundaries. They prefer incremental bandaids like type hints or unit tests that make it easier to deal with the big ball of mud, instead of not building the ball in the first place.

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

#84

Post by maleldil »

ansgri wrote: post #60
rcfox wrote: post #58

Earlier quoted context omitted.

Pretty much anywhere you're tempted to use a namedtuple, you should be using a dataclass[0] instead. And typing JSON-like data is possible with TypedDict[1]. [0] https://docs.python.org/3/library/dataclasses.html [1] https://docs.python.org/3/library/typing.html#typing.TypedDi...

Why? I thought one should prefer immutability. As for typed dicts.. yes, I’m mostly stuck on old python versions, nice reminder.

You can use TypedDict from `typing_extensions` if your version doesn't have it. You can use a lot of the newer stuff from there, too, especially if you enable `__future__.annotations`.

How old is your Python, though? TypedDict is from 3.8. That was 5 years ago.

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

#85

Post by maleldil »

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.

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

#86

Post by maleldil »

ansgri wrote: post #41
terminalbraid wrote: post #25

Sometimes I feel like we need an analog to javascript/typescript. Ptypethon if you will.

Absolutely. The main problem with python typing is that checking types is optional. A dialect with mandatory types (with inference) and runtime/load-time checking would be great.

Use pyright in strict mode, then. If you really want runtime checking, you can Pydantic's validation decorator, typeguard or beartype. Current typed python is much better than people give it credit. You just have to use it properly.

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

#87

Post by maleldil »

scoofy wrote: post #43

My objection to strong types in python is philosophical. Python mimics natural language, and natural language rejects strong types for context resolved ambiguity. In the way we resolve these issues in natural language, we can resolve bugs in python, that is, “do you mean integer ’3’ or string’3’” instead of insisting we define everything always forever. To me, people who use type hinting are just letting me know they…

> people who use type hinting are just letting me know they have written code that doesn’t check in line.

Yes, that's the point. We use typing so the type checker can find the mistakes for us instead of adding `isinstance` everywhere.

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

#88

Post by maleldil »

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.

> What is missing is mainstream adoption in libraries which is a matter of time.

I don't think that's a big problem anymore. Between typeshed and typing's overall momentum, most libraries have at least decent typing and those that don't often have typed alternatives.

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

#89

Post by junyjujfjf »

hbrn wrote: post #79
IshKebab wrote: post #72

Earlier quoted context omitted.

> when types weren't an option we weren't going towards the cliff Erm yes we were. Untyped Python wasn't magically tolerable just because type hints hadn't been implemented yet.

How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go? https://charliereese.ca/y-combinator-top-50-software-startup...

They are likely leveraging Django/Rails which treads the beaten path for Startups.

Startups are also more likely to do monoliths.

For Enterprise & microservices, you will start to see more Java/Go/C#.

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

#90

Post by adammarples »

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

None of those things came and went, they came but did not go. They're all still here, even in the 3.14 beta.
Post reply on HN