Python developers are embracing type hints • Hacker News Board

Re: Python developers are embracing type hints

#481

Post by makeitdouble » Sun, Sep 28, 2025, 10:18 PM UTC

9dev wrote: post #420

makeitdouble wrote: post #405

Earlier quoted context omitted.

> the lack of documentation If the code base expects flexibility, trusting documentation is the last thing you'd want to do. I know some people live and die by the documentation, but that's just a bad idea when duck typing or composition is heavily used for instance, and documentation should be very minimal in the first place. When a function takes a myriad of potential input, "can this function do X" is an answer yo…

Documentation doesn’t have to be an essay. A simple, automatically generated reference with proper types goes a long way to tell me „it can do that“ as opposed to „maybe it works lol“. That’s not the level of engineering quality I’m going for in my work.

This whole discussion is about how you might not want to be listing every single types a function accepts. I also kinda wonder how you automatically generate that for duck typing.

Re: Python developers are embracing type hints

#482

Post by bobbiechen » Sun, Sep 28, 2025, 10:18 PM UTC

detaro wrote: post #448

bobbiechen wrote: post #447

Earlier quoted context omitted.

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

Oops, thanks for the correction. That's on me for drive-by commenting.

Re: Python developers are embracing type hints

#483

Post by boltzmann64 » Sun, Sep 28, 2025, 10:30 PM UTC

tdeck wrote: post #253

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 Python a lot, and have been using it for personal projects since about 2010. It was only once I started working and encountering long-lived unfamiliar Python codebases regularly that I understood the benefits of type hints. It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. It's even less fun to find out that someone ma…

I am sorry, but whats wrong with doing something like, `print(type(var)); exit()` and just running it once instead of digging through 5-6 stack frames?

Re: Python developers are embracing type hints

#484

Post by joshribakoff » Sun, Sep 28, 2025, 11:04 PM UTC

oivey wrote: post #423

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"?

> That's your problem right there. Why are random callers sending whatever different input types to that function? Because it’s nice to reuse code. I’m not sure why anyone would think this is a design issue, especially in a language like Python where structural subtyping (duck typing) is the norm. If I wanted inheritance soup, I’d write Java. Ironically, that’s support for structural subtyping is why Protocols exist.…

Why can’t you re-use it with limited types? If the types are too numerous/hard to maintain it seems like the same would apply to the runtime code.

Re: Python developers are embracing type hints

#485

Post by mcronce » Sun, Sep 28, 2025, 11:24 PM UTC

chpatrick wrote: post #263

IshKebab wrote: post #163

Earlier quoted context omitted.

Mypy is trash but Pyright is very good.

I went from mypy to pyright to basedpyright and just started checking out pyrefly (the OP), and it's very promising. It's written in Rust so it's very efficient.

You know you can just use a compiled language with statically checked types, right?

Re: Python developers are embracing type hints

#486

Post by jkrejcha » Sun, Sep 28, 2025, 11:30 PM UTC

makeitdouble wrote: post #481

9dev wrote: post #420

Earlier quoted context omitted.

Documentation doesn’t have to be an essay. A simple, automatically generated reference with proper types goes a long way to tell me „it can do that“ as opposed to „maybe it works lol“. That’s not the level of engineering quality I’m going for in my work.

This whole discussion is about how you might not want to be listing every single types a function accepts. I also kinda wonder how you automatically generate that for duck typing.

Generally using the Protocol[1] feature

    from typing import Protocol

    class SupportsQuack(Protocol):
        def quack(self) -> None: ...

This of course works with dunder methods and such. Also you can annotate with @runtime_checkable (also from typing) to make `isinstance`, etc work with it

[1]: https://typing.python.org/en/latest/spec/protocol.html

Re: Python developers are embracing type hints

#487

Post by tickettotranai » Sun, Sep 28, 2025, 11:43 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…

I mean, you can just... Not annotate something if creating the relevant type is a pain. Static analysis \= type hints, and even then...

Besides, there must be some behavior you expect from this object. You could make a type that reflects this: IntIndexable or something, with an int index method and whatever else you need.

This feels like an extremely weak argument. Just think of it as self-enforcing documentation that also benefits auto-complete; what's not to love? Having an IntIndexable type seems like a great idea in your use case.

Re: Python developers are embracing type hints

#488

Post by [deleted] » Sun, Sep 28, 2025, 11:47 PM UTC

9dev wrote: post #420

makeitdouble wrote: post #405

Earlier quoted context omitted.

> the lack of documentation If the code base expects flexibility, trusting documentation is the last thing you'd want to do. I know some people live and die by the documentation, but that's just a bad idea when duck typing or composition is heavily used for instance, and documentation should be very minimal in the first place. When a function takes a myriad of potential input, "can this function do X" is an answer yo…

Documentation doesn’t have to be an essay. A simple, automatically generated reference with proper types goes a long way to tell me „it can do that“ as opposed to „maybe it works lol“. That’s not the level of engineering quality I’m going for in my work.

[deleted]

Re: Python developers are embracing type hints

#489

Post by hirvi74 » Sun, Sep 28, 2025, 11:49 PM UTC

k3vinw wrote: post #67

I really think that Rust has one of the best designed/inspired type systems. If I had to rewrite a Python project, I would consider Rust or another statically typed language before choosing to continue in a dynamic language with types bolted on. I hope the situation improves for dynamic languages with optional types, but it still feels weird and bolted onto the language because it is.

> or another statically typed language

I'm a professional .Net Core developer, but I'd throw my hat in the ring for Swift on this one. While obviously not exactly a 1:1 with Rust, there is definitely some common benefits between the two. Though, from what I understand of Rust (very little), its typing system is slightly more strict than Swift's which is slightly more strict than C#'s.

Re: Python developers are embracing type hints

#490

Post by rtpg » Sun, Sep 28, 2025, 11:56 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…

> For example a common failure mode in my work’s codebase is that some function will take something that is indexable by ints. The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types! And you better believe that every single admissible type will eventually be fed to this function. Sometimes people will try to keep up, annotating it with a Union of the (growing) list of admissible types, but eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.

You are looking for protocols. A bit futzy to write once but for a heavily trafficked function it's woth it.

If your JIT compiler doesn't work well with protocols... sounds like a JIT problem not a Python typing problem