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

161–170 of 209 posts

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

#161

Post by Hackbraten »

hopfenspergerj wrote: post #119
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`…

Ruff can automatically upgrade all of the issues you mentioned to match your target minimum python version.

Good to know, thanks!

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

#164

Post by pmontra »

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…

They invented .gitignore to prevent those files to get checked in into the repository.

Head, paper, keyboard is what we did in the 80s when compilers were too slow to afford throwing code at them and fix the errors later. Was that code in the HN story a substantial piece of code or some 100 lines program? Our programs used to be small.

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

#165

Post by kstrauser »

Der_Einzige wrote: post #122
aSanchezStern wrote: post #47

The thing that the author says they would prefer is already in Python, it's called NewType ( https://docs.python.org/3/library/typing.html#typing.NewType ) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation w…

Why is it that many of the examples for the "typing.protocal" class right below this involve meth??? Python WTF?

It’s a high level language.

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

#166

Post by kstrauser »

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…

A lot of the old robust code tended to have guard statements like “if not isinstance(…): raise ValueError”, which does a great job of surfacing mistakes before they can compound too much. We all wrote scads of production Python over the decades before typing caught on. I think it’s much easier to do a good job of it now. Having your IDE yell at you before you’ve even finished saving the file sure beats running it and hoping for the best.

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

#167

Post by Hackbraten »

Der_Einzige wrote: post #122
aSanchezStern wrote: post #47

The thing that the author says they would prefer is already in Python, it's called NewType ( https://docs.python.org/3/library/typing.html#typing.NewType ) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation w…

Why is it that many of the examples for the "typing.protocal" class right below this involve meth??? Python WTF?

`meth` is just a historical abbreviation.

Mind that support for methods as first-class objects was introduced with Python 2.5 [0].

That was in 2006, a few years before "meth" became engrained in European popular culture as an abbreviation for methamphetamines. The abbreviation was never changed.

[0]: https://docs.python.org/release/2.5/lib/typesmethods.html

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

#168

Post by kstrauser »

maxbond wrote: post #137
pansa2 wrote: post #135

Earlier quoted context omitted.

Type hints encourage this sort of object-oriented design though, in my experience. The resulting code is extremely verbose compared to Pythonic "executable pseudocode". For example, see Jack Diederich's talk "Stop Writing Classes": https://www.youtube.com/watch?v=o9pEzgHorH0

That talk had a big impact on my coding style. But citing a 99 line script written as an example for a blog post doesn't really support your argument. 99 lines is short, and verbosity is expected in such example code. Consider FastAPI. It uses functions as endpoints, like flask. Very compatible with "Stop Writing Classes." It also leverages type hinting to eliminate boilerplate and create more concise code. You don't…

Seconded, to all of that. Jack’s talk made a huge impression on me, too. So now I write almost no classes other than data containers, or maybe ones where I want to change some behavior without having a gazallion “isinstance” calls. All the happy little functions are thoroughly type decorated.

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

#169

Post by dcgudeman »

propagate97 wrote: post #163

Doesn't know how the first two things about python type hints. Must be shit. Great article...

honestly, that's how I read this article. Not sure why so many people seem to be agreeing with him... I guess it speaks to the general understanding about how to use python type hints

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

#170

Post by aragilar »

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've seen multiple major projects (such a sphinx) break on newer versions of Python due to changes in typing. Typing should make the code more robust, not less.
Post reply on HN