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

61–70 of 209 posts

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

#61

Post by VBprogrammer »

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).

I had a play with Dart a while back. It felt like Python with types designed in from the outset. Would quite like to use it more seriously.

It's in that funny position though where it is in danger of becoming synonymous with Flutter. Like Ruby and Rails.

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

#62

Post by rty32 »

belorn wrote: post #37
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).

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…

> 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 coding assistants. I happen to know as a matter of fact that the person who codes in Notepad++ frequently has trivial errors, and generally these people don't push code out as fast they could.

And they don't care to change the way they work even after seeing the alternatives and knowing they are objectively more efficient.

I am not their managers, so I say to myself "this is none of my business" and move on. I do feel pity for them.

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

#63

Post by hbrn »

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).

> 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 doesn't add up.

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

#64

Post by patrickkidger »

CJefferson wrote: post #54
Myrmornis wrote: post #29

Earlier quoted context omitted.

Can you give some examples of how the Python type system is disappointing you?

Mainly, the seems to be no way, in a dynamic language, to dynamically check if functions get the right types. To me, this means I don't really understand the python type hinting at all, as adding hints to just one or two functions provides no value to me at all. I assume I must be not using them usefully, as I've tried adding type hints to some projects and they just seemed to do nothing useful.

You want runtime typechecking.

See either beartype [1] or typeguard [2]. And if you're doing any kind of array-based programming (JAX or not), then jaxtyping [3].

[1] https://github.com/beartype/beartype/

[2] https://github.com/agronholm/typeguard

[3] https://github.com/patrick-kidger/jaxtyping

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

#65

Post by toxik »

greatgib wrote: post #42
Myrmornis wrote: post #28

Earlier quoted context omitted.

Python has union types, and you can type something as a container type with no type parameters.

You can but it defeats the purpose of typing. Makes a little bit more complicated to code and more verbose for almost no benefit. That is my point.

Hear, hear. I often spend five times as long peddling about with the type annotations. Most of the “bugs” I find with the type checker are type annotation bugs, not actual software bugs.

What type annotations do however deliver is useful completion via LSP.

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

#67

Post by hbrn »

belorn wrote: post #37
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).

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…

What's even worse, when typing is treated as an indisputable virtue (and not a tradeoff), pretty much every team starts sacrificing readability for the sake of typing.

And lo and behold, they end up with _more_ design bugs. And the sad part is that they will never even recognize that too much typing is to blame.

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

#68

Post by lblume »

rty32 wrote: post #62
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…

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

Well, using print over debuggers is fairly common in Rust and other languages with strong type systems because most bugs are, due to the extreme lengths the compiler goes to to able to detect them even before running the program, just lacks of information of the value of an expression at a single point in the program flow, which is where dbg! shines. I agree with all the other points though.

Anecdotally, I was just writing a generic BPE implementation, and spend a few hours tracking down a bug. I used debug statements to look at the values of expressions, and noticed that something was off. Only later did I figure out that I modified a value, but used the old copy — a simple logic error that #[must_use] could have prevented. cargo clippy -W pedantic is annoying, but this taught be I better listen to what it has to say.

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

#69

Post by dinosaurdynasty »

hbrn wrote: post #63
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).

> 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 a type annotation in sight.

There's also a larger understanding that as programs get larger and larger, they get harder to maintain and more importantly refactor, and good types help with this much more than brittle unit tests do. (You can also eliminate a lot of busywork tests with types.)

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

#70

Post by throwitaway1123 »

solidsnack9000 wrote: post #57

It seems like the author is looking for the ability to specify types as `typeof :arguments` and `typeof :return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.

TypeScript has the equivalent of what you're describing via the `Parameters` and `ReturnType` utility types [1][2], and I've found these types indispensable. So you can do the following:

  type R = ReturnType
  type P = Parameters
[1] https://www.typescriptlang.org/docs/handbook/utility-types.h...

[2] https://www.typescriptlang.org/docs/handbook/utility-types.h...

Post reply on HN