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

431–440 of 581 posts

Re: Python developers are embracing type hints

#431

Post by scuff3d »

chpatrick wrote: post #266
scuff3d wrote: post #23

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

Would you? Why? Python has a great experience for a bunch of tasks and with typing you get the developer experience and reliability as well.

No you don't. You get the illusion of static types without the actual upsides.

For any even medium sized project or anything where you work with other developers a statically typed language is always going to be better. We slapped a bunch of crap on Python to make it tolerable, but nothing more.

Re: Python developers are embracing type hints

#432

Post by scuff3d »

__MatrixMan__ wrote: post #350
scuff3d wrote: post #66

Earlier quoted context omitted.

I had someone say to me they preferred strict type checking in a Python linter over a statically typed language because they "don't like a build step"... Dudes it's literally just worse compilation with extra steps.

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.

Re: Python developers are embracing type hints

#433

Post by the__alchemist »

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…

I like your point! I think the advantage in its light is this: People often use Python because it's convention in the domain, the project already uses it, or it's the language the rest of the team uses. So, you are perhaps violating the spirit, but that's OK. You are making the most of tools available. It's not the Platonic (Pythonic??) ideal, but good enough.

Re: Python developers are embracing type hints

#434

Post by sdeframond »

j1elo wrote: post #306
sdeframond wrote: post #243

Earlier quoted context omitted.

It does! You can specify a protocol like this: class IntIndexable(Protocol[T]): def __getitem__(self, index: int, /) -> T: ... (Edit: formatting)

The syntax is definitely harder to grasp but if the mechanism is there, I guess the parent poster's concern can be solved like that. Although I understant that it might have been just a simplified example. Usually the " Real World " can get very complex.

> The syntax is definitely harder to grasp

Yes it is. I believe the reason is that this is all valid python while typescript is not valid javascript. Also, python's type annotations are available at runtime (eg. for introspection) while typescript types aren't.

That said, typescript static type system is clearly both more ergonomic and more powerful than Python's.

Re: Python developers are embracing type hints

#435

Post by lelanthran »

sevensor wrote: post #421
lelanthran wrote: post #388

Earlier quoted context omitted.

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

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 those with a ton of experience under their belt, who are comfortable with the language and its footguns due to decades of experience.

IOW, those people with little experience are not choosing C, and those that do choose it have already, over decades, internalised patterns to mitigate many of the problems.

At the end of the day, in 2025, I'd still rather maintain a system written in a statically typed language than a system written in a dynamically typed language.

Re: Python developers are embracing type hints

#436

Post by scuff3d »

ngrilly wrote: post #212
scuff3d wrote: post #41

Earlier quoted context omitted.

I'm not sure what you're trying to say here. If you mean Python's type annotations are erased at runtime... Okay? It still has runtime type information. It's not "erasure" as that term applies to Java for example. And Typescript compiles down to JavaScript, so obviously it's runtime behavior is going to be the same as JavaScript. In my view it's always a mistake to try and tac static typing on top of a dynamic one. I…

The fact that the types are reflected at runtime is what makes FastAPI/Pydantic possible, letting us use Python types to define data models used for serialization, validation, and generating. In TypeScript, we have to use something like Zod, instead of "normal" TypeScript types, because the types are not reflected at runtime.

I think a couple of things have to be untangled here.

The problem we are talking about in both Python and TS comes from the fact that they are (or compile down to) dynamic languages. These aren't issues in statically typed languages... because the code just won't compile it it's wrong and you don't have to worry about getting data from an untyped library.

I don't know a lot about Zod, but I believe the problem you are referring to is more about JavaScript then TS. JavaScript does a LOT of funky stuff at runtime, Python thank God actually enforces some sane type rules at runtime.

My point was not about how these two function at runtime. My point was that if you want to tac static typing onto a dynamic language, Typescripts approach is the better one, but even if can't fix the underlying issues with JS.

You could take a similar approach in Python. We could make a language called Tython, that is statically typed and then compiles down to Python. You eliminate an entire class of bugs at compile time, get a far more reliable experience then the current weirdness with gradual typing and linters, and you still get Pythons runtime type information to deal with things like interopt with existing Python code.

Re: Python developers are embracing type hints

#437

Post by marcosdumay »

knome wrote: post #347
coldtea wrote: post #324

Earlier quoted context omitted.

> you better believe that every single admissible type will eventually be fed to this function That's your problem right there. Why are random callers sending whatever different input types to that function? That said, there are a few existing ways to define that property as a type, why not a protocol type "Indexable"?

>why not a protocol type it was a sin that python's type system was initially released as a nominal type system. they should have been the target from day one. being unable to just say "this takes anything that you can call .hello() and .world() on" was ridiculous, as that was part of the ethos of the dynamically typed python ecosystem. typechecking was generally frowned upon, with the idea that you should accept any…

AFAIK, Python is missing a fully-featured up to date centralized documentation on how to use type annotations.

The current docs are "Microsoft-like", they have everything, spread through different pages, in different hierarchies, some of them wrong, and with nothing telling you what else exists.

Re: Python developers are embracing type hints

#438

Post by vjerancrnjak »

fyrn_ wrote: post #419
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…

You can use a Protocol type for that, makes a lot mote sense than nominal typing for typing use case.

Exactly, sounds like misuse of unions.

Although Python type hints are not expressive enough.

Re: Python developers are embracing type hints

#439

Post by dragonwriter »

coldtea wrote: post #324
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…

> you better believe that every single admissible type will eventually be fed to this function That's your problem right there. Why are random callers sending whatever different input types to that function? That said, there are a few existing ways to define that property as a type, why not a protocol type "Indexable"?

> Why are random callers sending whatever different input types to that function?

Probably because the actual type it takes is well-understood (and maybe even documented in informal terms) by the people making and using it, but they just don’t understand how to express it in the Python type system.

Re: Python developers are embracing type hints

#440

Post by marcosdumay »

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…

Software quality only pays off on the long time. For the short time, garbage is quick and gets the job done.

Also, in my experience, the long time for software arrives in a couple of weeks.

Post reply on HN