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

Python developers are embracing type hints

pyrefly.org

Post reply on HN
Print view View original

441–450 of 581 posts

Re: Python developers are embracing type hints

#441

Post by marcosdumay »

sota_pop wrote: post #317

Python types - all the onus of static types, with none of the performance! I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props. Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type…

> with none of the performance!

If you care about micro-optimizations, the first one that overwhelms everything else is to not use Python.

Anyway, if your types are onerous, you are using them wrong. Even more in a progressive type system where you always have the option of not using them or putting an "Any" there.

Re: Python developers are embracing type hints

#443

Post by __MatrixMan__ »

scuff3d wrote: post #432
__MatrixMan__ wrote: post #350

Earlier quoted context omitted.

I'm in favor of partitioning the set of reasons it can fail to compile into separate checks with separate tools. Taming the zoo of tooling is extra work, but smaller more focused tools are easier to work with once you understand their relationship to their neighbors. There's a world of difference between: > I've been using a different type checker and I like it, you should try it And > I'd like to switch our project…

Yes, if you are stuck with Python something is certainly better than nothing. But we shouldn't be writing large production apps in it in the first place.

Should we be writing large apps at all?

Re: Python developers are embracing type hints

#444

Post by scuff3d »

krzat wrote: post #105
scuff3d wrote: post #23

Or you could just use a statically typed language and get a much better experience.

Yeah, I thought lack of typing in python was intentional to support this another paradigm of programming for geniuses who don't need hand holding. Turns out they just didn't know any better?

How would a static type system have anything to do with handholding?

Re: Python developers are embracing type hints

#445

Post by mjr00 »

zahlman wrote: post #390
mjr00 wrote: post #78

Earlier quoted context omitted.

If your implication is that "implementing __add__ means you can use the + operator", you are incorrect. This is a common Python beginner mistake, but it isn't really a Python type checking issue, this is complexity with Python built-ins and how they interact with magic methods. My suggestion -- don't rely on magic methods.

This is a strange and aggressive bit of pedantry. Yes, you'd also need `__radd__` for classes that participate in heterogenous-type addition, but it's clear what was meant in context. The fundamentals are not all "beginner" level and beginners wouldn't be implementing operator overloads in the first place (most educators hold off on classes entirely for quite a while; they're pure syntactic sugar after all, and the u…

> This is a strange and aggressive bit of pedantry.

There's nothing pedantic about it. That's how Python works, and getting into the nuts and bolts of how Python works is precisely why the linked article makes type hinting appear so difficult.

> The entire point is that we have an intuition about what can be "added", but can't express it in the type system in any meaningful way.

As the post explores, your intuition is also incorrect. For example, as the author discovers in the process, addition via __add__/__radd__ is not addition in the algebraic field sense. There is no guarantee that adding types T + T will yield a T. Or that both operands are of the same type at all, as would be the case with "adding" a string and int. Or that A + B == B + A. We can't rely on intuition for type systems.

Re: Python developers are embracing type hints

#446

Post by scuff3d »

__MatrixMan__ wrote: post #443
scuff3d wrote: post #432

Earlier quoted context omitted.

Yes, if you are stuck with Python something is certainly better than nothing. But we shouldn't be writing large production apps in it in the first place.

Should we be writing large apps at all?

I don't know how to respond to this. Yes, large software projects do in fact exist...

Re: Python developers are embracing type hints

#447

Post by bobbiechen »

Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

Isn't this supported by typing.SupportsIndex? https://docs.python.org/3/library/typing.html#typing.Support...

Mind you, I haven't used it before, but it feels very similar to the abstract Mapping types.

Re: Python developers are embracing type hints

#448

Post by detaro »

bobbiechen wrote: post #447
Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

Isn't this supported by typing.SupportsIndex? https://docs.python.org/3/library/typing.html#typing.Support... Mind you, I haven't used it before, but it feels very similar to the abstract Mapping types.

__index__ is not what you think it is

Re: Python developers are embracing type hints

#449

Post by simonw »

lelanthran wrote: post #388
simonw wrote: post #262

Earlier quoted context omitted.

I didn't. I've been mainly a Python, PHP and JavaScript programmer for ~25 years and my experience with typed languages was mostly pre-type-inference Java which felt wildly less productive than my main languages.

> I didn't. I've been mainly a Python, PHP and JavaScript programmer for ~25 years Maybe its time you expanded your horizons, then. Try a few statically typed languages. Even plain C gives you a level of confidence in deployed code that you will not get in Python, PHP or Javascript.

I find automated tests give me plenty of confidence in the Python code I deploy. I'd rather deploy a codebase with comprehensive tests and no types over one with types and no tests.

I've been dabbling with Go for a few projects and found the type system for that to be pleasant and non-frustrating.

Re: Python developers are embracing type hints

#450

Post by ModernMech »

lelanthran wrote: post #435
sevensor wrote: post #421

Earlier quoted context omitted.

Maybe if your C has aggressive test coverage and you’re using Valgrind religiously and always checking errno when you’re supposed to and you’re checking the return value of everything. Otherwise lol. C as it’s written by middling teams is a soup of macros, three-star variables, and questionable data structure implementations, where everybody fiddles with everybody else’s data. I’ll take good C over bad Python, but go…

> C as it’s written by middling teams is a soup of macros, three-star variables, and questionable data structure implementations, where everybody fiddles with everybody else’s data. I’ll take good C over bad Python, but good C is rare. Ironically, the worst production C written in 2025 is almost guaranteed to be better than the average production Python, Javascript, etc. The only people really choosing C in 2025 are…

> The only people really choosing C in 2025 are those with a ton of experience under their belt, who are comfortable with the language and its footguns due to decades of experience.

Experienced users of C can't be the only people who use it if the language is going to thrive. It's very bad for a language when the only ones who speak it are those who speak it well. The only way you get good C programmers is by cultivating bad C programmers, you can't have one without the other. If you cut off the bad programmers (by shunning or just not appealing to them, or loading your language with too many beginner footguns), there's no pipeline to creating experts, and the language dies when the experts do.

The people who come along to work on their legacy systems are better described as archaeologists than programmers. COBOL of course is the typical example, there's no real COBOL programming community to speak of, just COBOL archeologists who maintain those systems until they too shall die and it becomes someone else's problem, like the old Knight at the end of Indiana Jones.

Post reply on HN