Python developers are embracing type hints • Hacker News Board

Re: Python developers are embracing type hints

#381

Post by overgard » Sun, Sep 28, 2025, 3:09 PM UTC

pydry wrote: post #138

adalacelove wrote: post #118

Earlier quoted context omitted.

People adapt to the circumstances. A lot of Python uses are no longer about fast iteration on the REPL. Instead of that we are shipping Python to execute in clusters on very long running jobs or inside servers. It's not only about having to start all over after hours, it's simply that concurrent and distributed execution environments are hostile to interactive programming. Now you can't afford to wait for an exceptio…

Here we are because: * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. * Types are incredibly valuable on hardened production code. * Most good production code started out spikey, experimental or as an MVP and transitioned . And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has…

I don't think types are expensive for MVP code unless they're highly complicated (but why would you do that?) Primitives and interfaces are super easy to type and worth the extra couple seconds.

Re: Python developers are embracing type hints

#382

Post by tetha » Sun, Sep 28, 2025, 3:09 PM UTC

seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

I think that the practically available type checkers evolved to a point where many of the common idioms can be expressed with little effort.

If one thinks back to some of the early statically typed languages, you'd have a huge rift: You either have this entirely weird world of Caml and Haskell (which can express most of what python type hints have, and could since many years), and something like C, in which types are merely some compiler hints tbh. Early Java may have been a slight improvement, but eh.

Now, especially with decent union types, you can express a lot of idioms of dynamic code easily. So it's a fairly painless way to get type completion in an editor, so one does that.

Re: Python developers are embracing type hints

#383

Post by almosthere » Sun, Sep 28, 2025, 3:14 PM UTC

untrust wrote: post #366

coldtea wrote: post #326

Earlier quoted context omitted.

> It's a boon if the goal is to write code then go home. It's a loaded footgun if the goal is to compose a stack and run it in production within SLO. Never has been an issue in practice...

Did you forget /s at the end of this? I work at big tech and the number of bad deploys and reverts I've seen go out due to getting types wrong is in the hundreds. Increased type safety would catch 99% of the reverts I've seen.

Also have fun depending on libraries 10 years old as no one likes upgrades over fear of renames.

Re: Python developers are embracing type hints

#384

Post by jonas21 » Sun, Sep 28, 2025, 3:18 PM UTC

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…

> eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.

No, this is the great thing about gradual typing! You can use it to catch errors and provide IDE assistance in the 90% of cases where things have well-defined types, and then turn it off in the remaining 10% where it gets in the way.

Re: Python developers are embracing type hints

#385

Post by true_blue » Sun, Sep 28, 2025, 3:19 PM UTC

humdaanm wrote: post #376

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…

the issue of having multiple inputs able to be indexable by ints, is exactly why i prefer that type hints remain exactly as "hints" and not as mandated checks. my philosophy for type hints is that they are meant to make codebases easier to understand without getting into a debugger. their functional equivalence should be that of comments. it's a cleaner more concise way of describing a variable instead of using a ful…

>though maybe there's a path forward to give a variable a sort of "de-hint" in that in can be everything BUT this type

I think this is called a negation type, and it acts like a logical NOT operator. I'd like it too, and I hear that it works well with union types (logical OR) and intersection types (logical AND) for specifying types precisely in a readable way.

Re: Python developers are embracing type hints

#386

Post by dandanua » Sun, Sep 28, 2025, 3:21 PM UTC

jakobnissen wrote: post #139

dandanua wrote: post #83

This is why I think Julia will win in the long run. It has an amazing type system, simple yet powerful. In particular, abstract types are much easier to define and use than abstract classes in Python.

Ooh, I completely disagree. Julia has a worse type system overall, IMO. The big downside of Julia is that Julia has no interfaces or protocols. So, you can't type assert that something is an iterable of integers, for example. Another issue is that abstract types are completely undocumented and have no tooling support. You say it's easier to use an abstract type. Can you tell me what I need to define to create a worki…

There are no traits in Julia by default, that's true. But since types are first class citizens in Julia, traits can be implemented within the language. There is a package SimpleTraits.jl that implements Holy's trait trick, see also this tutorial https://ahsmart.com/pub/holy-traits-design-patterns-and-best...

An ability to work with types within the language is already a win for me.

Re: Python developers are embracing type hints

#387

Post by Syntaf » Sun, Sep 28, 2025, 3:22 PM UTC

simonw wrote: post #25

The thing that finally got me on board with optional type hints in Python was realizing that they're mainly valuable as documentation. But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful.

This resonates with me this so much. I feel like half the comments in this thread are missing the value typing, but maybe they've never had the misfortune of working with hundreds of other developers on a project with no defined contracts on aggregates / value objects outside of code comments and wishful thinking.

I've worked on large python codebases for large companies for the last ~6 years of my career; types have been the single biggest boon to developer productivity and error reduction on these codebases.

Just having to THINK about types eliminates so many opportunities for errors, and if your type is too complex to express it's _usually_ a code smell; most often these situations can be re-written in a more sane albeit slightly verbose fashion, rather than using the more "custom" typing features.

No one gets points for writing "magical" code in large organizations, and typing makes sure of this. There's absolutely nothing wrong with writing "boring" python.

Could we have accomplished this by simply having used a different language from the beginning? Absolutely, but often times that's not a option for a company with a mature stack.

TL;DR -- Typing in python is an exception tool to scale your engineering organization on a code-base.

Re: Python developers are embracing type hints

#388

Post by lelanthran » Sun, Sep 28, 2025, 3:24 PM UTC

simonw wrote: post #262

lelanthran wrote: post #168

Earlier quoted context omitted.

> The thing that finally got me on board with optional type hints in Python was realizing that they're mainly valuable as documentation. > But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful. So ... you didn't have this realisation prior to using Python type hints? Not from any other language you used prior to Python?

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.

Re: Python developers are embracing type hints

#389

Post by bartread » Sun, Sep 28, 2025, 3:24 PM UTC

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…

> The reason is that they are not really a part of the language, they violate the spirit of the language

This is a good way of expressing my own frustration with bolting strong typing on languages that were never designed to have it. I hate that TypeScript has won out over JavaScript because of this - it’s ugly, clumsy, and boilerplatey - and I’d be even more disappointed to see the same thing happen to the likes of Python and Ruby.

My background is in strongly typed languages - first C++, then Java, and C# - so I don’t hate them or anything, but nowadays I’ve come to prefer languages that are more sparing and expressive with their syntax.

Re: Python developers are embracing type hints

#390

Post by zahlman » Sun, Sep 28, 2025, 3:25 PM UTC

mjr00 wrote: post #78

MrJohz wrote: post #75

Earlier quoted context omitted.

How is "responds to the `__add__` method" anywhere close to equivalent to `Any`?

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 use case is often hard to explain to beginner).

Regardless, none of that bears on the original `slow_add` example from the Reddit page. 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. Because the rule is something like "anything that says it can be added according to the protocol — which in practical terms is probably any two roughly-numeric types except for the exceptions, and also most container types but only with other instances of the same type, and also some third-party things that represent more advanced mathematical constructs where it makes sense".

And saying "don't rely on magic methods" does precisely nothing about the fact that people want the + symbol in their code to work this way. It does suggest that `slow_add` is a bad thing to have in an API (although that was already fairly obvious). But in general you do get these issues cropping up.

Dynamic typing has its place, and many people really like it, myself included. Type inference (as in the Haskell family) solves the noise problem (for those who consider it a problem rather than something useful) and is elegant in itself, but just not the strictly superior thing that its advocates make it out to be. People still use Lisp family languages, and for good reason.

But maybe Steve Yegge would make the point better.