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

411–420 of 581 posts

Re: Python developers are embracing type hints

#411

Post by preciousoo »

zx8080 wrote: post #307
kketch wrote: post #249

Earlier quoted context omitted.

Well, precisely: - There is one obvious way to provide type hints for your code, it’s to use the typing module provided by the language which also provides syntax support for it. - You don’t have to use it because not all code has to be typed - You can use formatted strings, but you don’t have to - You can use comprehensions but you don’t have to - You can use async io, but you don’t have to. But it’s the one obvious…

> but there are only one way to use them Optional nature of those features conflicts with this statement. As optionality means two ways already.

classes are optional in python, does that violate the spirit?

Re: Python developers are embracing type hints

#412

Post by kketch »

yladiz wrote: post #300
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

Actually in Python it can. Since the type hints are accessible at runtime, library authors can for example change which values in kwargs are allowed based on the type of the argument. So on the language level it doesn’t directly change the behavior, but it is possible to use the types to affect the way code works, which is unintuitive. I think it was a bad decision to allow this, and Python should have opted for a Ty…

You can make it change the behaviour at runtime is different than it changes the behaviour at runtime I think?

Lots of very useful tooling such as dataclasses and framework like FastAPI rely on this and you're opinion is that it's a bad thing why?

In typescript the absence of type annotations reflection at runtime make it harder to implement things that people obviously want, example, interop between typescript and zod schemas. Zod resorts instead to have to hook in ts compiler to do these things.

I'm honestly not convinced Typescript is better in that particular area. What python has opted for is to add first class support for type annotations in the language (which Javascript might end up doing as well, there are proposals for this, but without the metadata at runtime). Having this metadata at runtime makes it possible to implement things like validation at runtime rather than having to write your types in two systems with or without codegen (if Python would have to resort to codegen to do this, like its necessary in typescript, I would personally find this less pythonic).

I think on the contrary it allows for building intuitive abstractions where typescript makes them harder to build?

Re: Python developers are embracing type hints

#413

Post by crabbone »

bc569a80a344f9c wrote: post #260
crabbone wrote: post #234

Earlier quoted context omitted.

The way I understand parent is that such a type would be too broad. The bigger problem is that the type system expressed through hints in Python is not the type system Python is actually using. It's not even an approximation. You can express in the hint type system things that are nonsense in Python and write Python that is nonsense in the type system implied by hints. The type system introduced through typing packag…

> In Russian, there's an expression "like a saddle on a cow", I'm not sure what the equivalent in English would be “To fit a square peg into a round hole”

Close but not the same. In Russian, the expression implies an "upgrade", a failed attempt at improving something that either doesn't require improvement or cannot be improved in this particular way. This would be a typical example of how it's used: "I'm going to be a welder, I need this bachelor's degree like a saddle on a cow!".

Re: Python developers are embracing type hints

#414

Post by crabbone »

throw-the-towel wrote: post #364
crabbone wrote: post #234

Earlier quoted context omitted.

The way I understand parent is that such a type would be too broad. The bigger problem is that the type system expressed through hints in Python is not the type system Python is actually using. It's not even an approximation. You can express in the hint type system things that are nonsense in Python and write Python that is nonsense in the type system implied by hints. The type system introduced through typing packag…

"Lipstick on a pig"? Although that's quite more combative than the Russian phrase.

Yeah... this seems like it would fit the bill nicely. At least, this is the way I'd translate it if I had to. Just didn't think about it.

Re: Python developers are embracing type hints

#416

Post by pjmlp »

Izkata wrote: post #410
9dev wrote: post #225

Earlier quoted context omitted.

That's the same complaints people had about TypeScript in the beginning, when libraries such as Express used to accept a wide range of input options that would be a pain to express in types properly. If you look at where the ecosystem is now, though, you'll see proper type stubs, and most libraries get written in TS in the first place anyway. When editing TS code, you get auto-completion out of the box, even for deep…

Except Typescript embraces duck typing. You can say "accept any object with a quack() method", for example, and it'll accept an unexpected quacking parrot. It can even tell when two type definitions are close enough and merge them.

Kind of, depends on the compiler configuration.

Re: Python developers are embracing type hints

#417

Post by zelphirkalt »

whilenot-dev wrote: post #354
zelphirkalt wrote: post #311

Earlier quoted context omitted.

I think this pipeline implementation does some things different from what I wanted (but did not precisely describe. It seems that each step is run right away, as it is "added", rather than collected and run when `terminate` is called. Also each step can only consume the result of the previous step, not the results of earlier steps. This can be worked around, by ending the pipeline and then starting multiple pipelines…

> Or is `class Pipeline[T]:` a short form of that? Yes, since 3.12. > Pipeline would need to change result type with each call of `add_step`, which seems like current type checkers cannot statically check. Sounds like you want a dynamic type with your implementation (note the emphasis). Types shouldn't change at runtime, so a type checker can perform its duty. I'd recommend rethinking the implementation. This is the…

Thanks for your efforts. I didn't expect and couldn't expect anyone to invest time into trying to make this work. I might try your version soon.

Re: Python developers are embracing type hints

#418

Post by bityard »

pansa2 wrote: post #241
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

"There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer. It was originally meant as a counterpoint to Perl's "there's more than one way to do it," to show that the Python developers put a priority on quality and depth of features rather than quantity.

But times change and these days, Python is a much larger language with a bigger community, and there is a lot more cross-pollination between languages as basic philosophical differences between the most popular languages steadily erode until they all do pretty much the same things, just with different syntax.

Re: Python developers are embracing type hints

#419

Post by fyrn_ »

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.

Re: Python developers are embracing type hints

#420

Post by 9dev »

makeitdouble wrote: post #405
fn-mote wrote: post #299

Earlier quoted context omitted.

> Because the flexibility has been a boon and not a problem Well, you could say that the problem in this case was the lack of documentation, if you wanted. The type signature could be part of the documentation, from this point of view. Let me give a kind-of-concrete example: one year I was working through a fast.ai course. They have a Python layer above the raw ML stuff. At the time, the library documentation was med…

> 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.
Post reply on HN