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

211–220 of 581 posts

Re: Python developers are embracing type hints

#211

Post by Mond_ »

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…

> * 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, footguns, very difficult, presumably requires a cmake guy), Java (very restrictive, slow iteration and startups, etc.). Compared to those just using Python sounds decent.

Nowadays we have Go and Rust, both of which are pretty easy to iterate in (for different reasons).

Re: Python developers are embracing type hints

#212

Post by ngrilly »

scuff3d wrote: post #41
Spivak wrote: post #28

Earlier quoted context omitted.

But TypeScript erases (its) types at runtime, exactly like Python. Python is Python's TypeScript. Whether you want TS or JS-like semantics is entirely dependent on whether you use a type checker and whether you consider its errors a build breaker.

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.

Re: Python developers are embracing type hints

#213

Post by kitd »

xurukefi wrote: post #210

For me, type hints are mainly useful because they're the only reliable way to get decent IDE auto-completion. Beyond that, they feel like a bolted-on compromise that goes against the spirit of Python. If you really need strict typing, you're probably better off using a statically typed language.

JSDoc plays a similar role with Javascript. Moreover it is supported out of the box by VSCode, so add a few JSDoc comments to your types and functions, and intellisense instantly kicks in.

Re: Python developers are embracing type hints

#214

Post by baobun »

ninetyninenine wrote: post #142
quietbritishjim wrote: post #104

Earlier quoted context omitted.

That's not a benefit. That's a monstrosity. And, as you heavily imply in your post, type checkers won't be able to cope with it, eliminating one if the main benefits of type hints. Neither will IDEs / language servers, eliminating the other main benefit.

>And, as you heavily imply in your post, type checkers won't be able to cope with it I implied no such thing. literally said there's a language that already does this. Typescript. IDE's cope with it just fine. >That's not a benefit. That's a monstrosity. So typescript is a monstrosity? Is that why most of the world who uses JS in node or the frontend has moved to TS? Think about it.

I don't believe Typescript (nor Idris) type systems work like you describe, though? Types aren't programmable with code like that (in the same universe, as you say) and TS is structurally typed, with type erasure (ie types are not available at runtime).

I am not that deeply familiar with Python typings development but it sounds fundamentally different to the languages you compare to.

Re: Python developers are embracing type hints

#215

Post by Dr_Birdbrain »

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

So, if the jit compiler needs the annotation I am happy to provide it, but otherwise I will proactively not provide any, and I will sometimes even delete existing annotations when they are devolving into silliness.

Re: Python developers are embracing type hints

#216

Post by chrysoprace »

ctxc wrote: post #195

For some reason, I find typing in Python to be more ergonomic and "get out of your way" compared to Typescript. But they both seem to handle typing similarly. I can't put my finger on why. Anybody else?

TypeScript is kind of all or nothing.

It's not quite all or nothing, but it's annoying to work with it if you only use it for some things and not for others. I find that if you have a mixture of TS and JS in various files I would rather just go all in on TypeScript so I don't have to manually annotate.

With Python you're still just working with Python files.

Re: Python developers are embracing type hints

#217

Post by jampekka »

ninetyninenine wrote: post #112
JimDabell wrote: post #102

Earlier quoted context omitted.

> It can actually roughly reduce dev time by 50% and increase safety by roughly 2x. Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario…

>Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? My own anecdotal metric. Isn't that obvious? The initial post was an anecdotal opinion as well. I don't see a problem here. >In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other k…

> If you used both untyped languages and typed languages extensively you will know that types are intrinsically better. It's not even a contest. Anyone who still debates this stuff just lacks experience.

Or have enough experience to have lived e.g. the J2EE and C++ template hells and see where this is going.

Re: Python developers are embracing type hints

#218

Post by Too »

_flux wrote: post #120
Too wrote: post #106

Earlier quoted context omitted.

This is trivial to solve by simply not having circular imports. Place the types in one file and the usage of it in others. This has many benefits, like forcing you to think about the dependencies and layers of your architecture. Here is a good read about why, from F# that has the same limitation https://fsharpforfunandprofit.com/posts/cyclic-dependencies/ As others already mentioned, importing __annotations__ also wo…

If the type is a class with methods, then this method doesn't work, though adding intermediate interface classes (possibly with Generic types) might help in most cases. Python static type system isn't quite the same level as F#. > Well, these complaints are unfounded. "You're holding it wrong." I've also coded quite a bit of OCaml and it had the same limitation (which is where F# picked it up in the first place), and…

> If the type is a class with methods, then this method doesn't work

Use typing.Self

Re: Python developers are embracing type hints

#219

Post by chrysoprace »

tmarice wrote: post #181

Type hints in Python add a great amount of visual noise to the code, and I actively avoid them wherever possible. If static typing is a must, use a language where static typing is not an afterthought, and let Python be Python.

Would you rather deal with a little visual noise or a runtime exception that you could've caught before code got to production? For me it's about tradeoffs, and so far the tradeoff has been well worth it.

Re: Python developers are embracing type hints

#220

Post by detaro »

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…

Can't you define your own hint for "type that has __getitem__ taking int"?
Post reply on HN