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

401–410 of 581 posts

Re: Python developers are embracing type hints

#401

Post by burnerRhodov2 »

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.

Re: Python developers are embracing type hints

#402

Post by vintagedave »

My permanent instructions to Claude are:

* Always strongly type, for local variables, method parameters, and return types

* Avoid Any unless absolutely required

* hasattr() and get() are often code smells; if the type can be known, use that type

* Use beartype for all methods.

I _love_ beartype and want to plug it to everyone on HN: https://github.com/beartype/beartype

I'm building my own coding agent, like Claude, and it is built with opinionated style. Strongly typing Python and using beartype are what it will try to do unless the user specifies otherwise.

Re: Python developers are embracing type hints

#403

Post by ModernMech »

crabbone wrote: post #227
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.

Same nonsense repeated over and over again... There aren't dynamic languages. It's not a thing. The static types aren't what you think they are... You just don't know what you are saying and your conclusion is just a word salad. What happened to Python is that it used to be a "cool" language, whose community liked to make fun of Java for their obsession with red-taping, which included the love for specifying unnecess…

Yeah, this is the lens through which I view it. It's a sort of colonization that happens, when corporations realize a language is fit for plunder. They start funding it, then they want their people on the standards boards, then suddenly the direction of the language is matched very nicely to their product roadmap. Meanwhile, all the people who used to make the language what it was are bought or pushed out, and the community becomes something else entirely.

Re: Python developers are embracing type hints

#404

Post by zahlman »

afiori wrote: post #183
zahlman wrote: post #60

Earlier quoted context omitted.

> They don't seem to come with the benefits of optimisation that you get with static typed languages They don't. And cannot, for compatibility reasons. Aside from setting some dunders on certain objects (which are entirely irrelevant unless you're doing some crazy metaprogramming thing), type annotations have no effect on the code at runtime. The Python runtime will happily bytecode-compile and execute code with inco…

Now that python has a jit it could use them (not saying it should) for speculative compilation My understanding is that currently python can collect type data in test runs and use it to inform the jit during following executions

> Now that python has a jit it could use them (not saying it should) for speculative compilation

I'd forgotten about that. Now that you mention it, my understanding is that this is actually the plan.

Re: Python developers are embracing type hints

#405

Post by makeitdouble »

fn-mote wrote: post #299
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.

> 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 you get by reading the function or the tests, not the prose on how it was intended 10 years ago or how some other random dev thinks it works.

Re: Python developers are embracing type hints

#406

Post by nbadg »

theptip wrote: post #395
mhitza wrote: post #391

Earlier quoted context omitted.

Sounds like the ecosystem needs an "indexable" type annotation. Make it an "indexable " for good measure.

Right, this was my thought. Can’t you just use a typing.Protocol on __getitem__ here? https://typing.python.org/en/latest/spec/protocol.html Something like from typing import Protocol class Indexable(Protocol): def __getitem__(self, i: int) -> Self: ... Though maybe numpy slicing needs a bit more work to support

Indeed.

IMO, the trick to really enjoying python typing is to understand it on its own terms and really get comfortable with generics and protocols.

That being said, especially for library developers, the not-yet-existant intersection type [1] can prove particularly frustrating. For example, a very frequent pattern for me is writing a decorator that adds an attribute to a function or class, and then returns the original function or class. This is impossible to type hint correctly, and as a result, anywhere I need to access the attribute I end up writing a separate "intersectable" class and writing either a typeguard or calling cast to temporarily transform the decorated object to the intersectable type.

Also, the second you start to try and implement a library that uses runtime types, you've come to the part of the map where someone should have written HERE BE DRAGONS in big scary letters. So there's that too.

So it's not without its rough edges, and protocols and overloads can be a bit verbose, but by and large once you really learn it and get used to it, I personally find that even just the value of the annotations as documentation is useful enough to justify the added work adding them.

[1] https://github.com/python/typing/issues/213

Re: Python developers are embracing type hints

#407

Post by dahauns »

Mond_ wrote: post #211
pydry wrote: post #138

Earlier quoted context omitted.

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…

> * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. This is what people say, but I don't think it's correct. What is correct is that say, ten to twenty years ago, all the statically typed languages had other unacceptable drawbacks and "types bad" became a shorthand for these issues. I'm talking about C (nonstarter for obvious reasons), C++ (a huge mess, fo…

I think Java was the main one. C/C++ are (relatively) close to the metal, system-level languages with explicit memory management - and were tacitly accepted to be the "complicated" ones, with dynamic typing not really applicable at that level.

But Java was the high-level, GCed, application development language - and more importantly, it was the one dominating many university CS studies as an education language before python took that role. (Yeah, I'm grossly oversimplifying - sincere apologies to the functional crowd! :) )

The height of the "static typing sucks!" craze was more like a "The Java type system sucks!" craze...

Re: Python developers are embracing type hints

#408

Post by sevensor »

blibble wrote: post #348
sota_pop wrote: post #317

Python types - all the onus of static types, with none of the performance! I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props. Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type…

I find the type hints harder and slower than java/C/... try typing a decorator, or anything using file IO I find it extremely difficult, if not impossible, and I did type theory (the type checkers being really, really stupid doesn't help either)

So don’t? Just annotate the stuff that’s not annoying. I agree, IO is annoying to type. Decorators are fine, it’s just a function that returns a function. It’s still a win, however much you decide to annotate.

Re: Python developers are embracing type hints

#410

Post by Izkata »

9dev wrote: post #225
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…

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