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

491–500 of 581 posts

Re: Python developers are embracing type hints

#491

Post by jkrejcha »

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…

I disagree. I think, if the decision was made today, it probably would have ended up being structural, but the fact that it isn't enables (but doesn't necessarily force) Python to be more correct than if it weren't (whereas forced structural typing has a certain ceiling of correctness).

Really it enabled the Python type system to work as well as it does, as opposed to TypeScript, where soundness is completely thrown out except for some things such as enums

Nominal typing enables you to write `def ft_to_m(x: Feet) -> Meters: and be relatively confident that you're going to get Feet as input and Meters as output (and if not, the caller who ignored your type annotations is okay with the broken pieces).

The use for protocols in Python in general I've found in practice to be limited (the biggest usefulness of them come from the iterable types), when dealing with code that's in a transitional period, or for better type annotations on callables (for example kwargs, etc).

Re: Python developers are embracing type hints

#492

Post by pdonis »

mjr00 wrote: post #454
pdonis wrote: post #399

Earlier quoted context omitted.

> treating the `+` operator the same as you would an interface method In other words, you agree that the Python type hint system does not give you a good, built-in way to express the "Addable" type. Which means you are contradicting your claims that the type the article wants to express is "unknown" and that the article is advocating using "Any" for this case. The type is not unknown--it's exactly what I said: "doesn…

> I don't see why. Addition is a very commonly used operation, and being able to have a type system that can express "this function takes two arguments that can be added using the addition operator" seems like something any type system that delivers the goods it claims to deliver ought to have. If your comparison is Rust, sure, but you can't even express this in Java. No, Java's type system is not great, but it's a t…

> it is factually and objectively an esoteric and unusual case.

Sorry, but your unsupported opinion is not "factual and objective".

> If your argument is that all type systems are bad or deficient

I said no such thing, any more than the article did. Again you are attacking a straw man. (If you had said "limited in what they can express", I might buy that. But you didn't.)

I think I've said all I have to say in this subthread.

Re: Python developers are embracing type hints

#493

Post by jshen »

Balinares wrote: post #316
zelphirkalt wrote: post #281

Earlier quoted context omitted.

Because the flexibility has been a boon and not a problem. The problem only comes when you try to express everything in the type system, that is third party (the type checkers for it) and added on top.

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. Python type hints manage to largely preserve the flexibility while seriously increasing confidence in the correctness, and lack of crashing corner cases, of each component. There's really no good case against them at this point outside of one-off scripts. (And even there,…

People say this all the time, but I've never seen any data proving it's true. Should be rather easy too, I'm at a big company and different teams use different languages. The strictly typed languages do to have fewer defects, and those teams don't ship features any faster than the teams using loosely typed languages.

What I've experienced is that other factors make the biggest difference. Teams that write good tests, have good testing environments, good code review processes, good automation, etc tend to have fewer defects and higher velocity. Choice of programming language makes little to no difference.

Re: Python developers are embracing type hints

#494

Post by makeitdouble »

jkrejcha wrote: post #486
makeitdouble wrote: post #481

Earlier quoted context omitted.

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

You're then creating a Protocol for every single function that could rely on some duck typing.

Imagine one of your function just wants to move an iterator forward, and another just wants the current position. You're stuck with either requiring a full iterator interface when only part of it is needed or create one protocol for each function.

In day to day life that's dev time that doesn't come back as people are now spending time reading the protocol spaghetti instead of reading the function code.

I don't deny the usefulness of typing and interfaces in stuff like libraries and heavily used common components. But that's not most of your code in general.

Re: Python developers are embracing type hints

#495

Post by mixmastamyk »

bgwalter wrote: post #379
anankaie wrote: post #373

Earlier quoted context omitted.

> Google and Microsoft have already shut down several failed projects Could you elaborate on this?

Sure: Google fired the Python language team in 2024 that contained a couple of the worst politicians who were later involved in slandering Tim Peters. Before that, Google moved heavily from Python to Go. Microsoft fired the "Faster CPython Team" this year.

It’s unlikely those layoffs are related to that, but rather the industry at large and end of zirp. Those type of folks are common in bigtech companies as well.

For example the dart/flutter team was decimated as well.

Re: Python developers are embracing type hints

#496

Post by pas »

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

if the piece of code in question is so type independent, then either it should be generic or it's doing too much

Re: Python developers are embracing type hints

#497

Post by chlorion »

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

That's not how you are supposed to use static typing? Python has "protocols" that allows for structural type checking which is intended for this exact problem.

Re: Python developers are embracing type hints

#498

Post by chlorion »

burnerRhodov2 wrote: post #401
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 explained some hyper niche instance where type hints should be ignored. 99% of the time, they are extremely helpful.

It's not even a niche instance, protocols solve their problem lol.

Re: Python developers are embracing type hints

#499

Post by jshen »

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.

Trends change. There is still no hard evidence that static types are net positive outside of performance.

Re: Python developers are embracing type hints

#500

Post by mjr00 »

pdonis wrote: post #492
mjr00 wrote: post #454

Earlier quoted context omitted.

> I don't see why. Addition is a very commonly used operation, and being able to have a type system that can express "this function takes two arguments that can be added using the addition operator" seems like something any type system that delivers the goods it claims to deliver ought to have. If your comparison is Rust, sure, but you can't even express this in Java. No, Java's type system is not great, but it's a t…

> it is factually and objectively an esoteric and unusual case. Sorry, but your unsupported opinion is not "factual and objective". > If your argument is that all type systems are bad or deficient I said no such thing, any more than the article did. Again you are attacking a straw man. (If you had said "limited in what they can express", I might buy that. But you didn't.) I think I've said all I have to say in this s…

It's factual and objective that billions, if not trillions of lines of Java and Go have been deployed and the language still cannot express "supports the + operator" as a type constraint. In production, non-academic settings, people don't generally write code like that.

Again, this is an esoteric limitation from the perspective of writing code that runs working software, not a programming language theory perspective.

Post reply on HN