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

341–350 of 581 posts

Re: Python developers are embracing type hints

#341

Post by ninetyninenine »

jampekka wrote: post #217
ninetyninenine wrote: post #112

Earlier quoted context omitted.

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

typing can get extreme to the point where it becomes proof based typing. So I know what you mean here. I've lived through it and done it.

In general types outweigh no types EVEN with the above.

Re: Python developers are embracing type hints

#342

Post by amluto »

thr0w4w4y1337 wrote: post #221
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…

from typing import Protocol, TypeVar T_co = TypeVar("T_co", covariant=True) class Indexable(Protocol[T_co]): def __getitem__(self, i: int) -> T_co: ... def f(x: Indexable[str]) -> None: print(x[0]) I am failing to format it proprely here, but you get the idea.

I give Rust a lot of points for putting control over covariance into the language without making anyone remember which one is covariance and which one is contravariance.

Re: Python developers are embracing type hints

#343

Post by sevensor »

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 don’t know anything about your jit compiler, but generally the value I get from type annotations has nothing to do with what they do at runtime. People get so confused about Python’s type annotations because they resemble type declarations in languages like C++ or Java. For the latter, types tell the compiler how to look up fields on, and methods that apply to, an object. Python is fine without that.

Python’s types are machine-checkable constraints on the behavior of your code.. Failing the type checker isn’t fatal, it just means you couldn’t express what you were doing in terms it could understand. Although this might mean you need to reconsider your decisions, it could just as well mean you’re doing something perfectly legitimate and the type checker doesn’t understand it. Poke a hole in the type checker using Any and go on with your day. To your example, there are several ways described in comments by me and others to write a succinct annotation, and this will catch cases where somebody tries to use a dict keyed with strings or something.

Anyway, you don’t have to burn a lot of mental energy on them, they cost next to nothing at runtime, they help document your function signatures, and they help flag inconsistent assumptions in your codebase even if they’re not airtight. What’s not to like?

Re: Python developers are embracing type hints

#344

Post by hnlmorg »

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.

I find I’ve spent so much time writing with typed code that I now find it harder to write POC code in dynamic languages because I use types to help reason about how I want to architect something.

Eg “this function should calculate x and return”, well if you already know what you want the function to do then you know what types you want. And if you don’t know what types you want then you haven’t actually decided what that function should do ahead of building it.

Now you might say “the point of experimental code is to figure out what you want functions to do”. But even if you’re writing an MVP, you should know what that each function should do by the time you’ve finished writing it. Because if you don’t know who to build a function then how do you even know that the runtime will execute it correctly?

Re: Python developers are embracing type hints

#345

Post by [deleted] »

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…

[deleted]

Re: Python developers are embracing type hints

#346

Post by baobabKoodaa »

drekipus wrote: post #96
lysace wrote: post #30

Earlier quoted context omitted.

Decent argument in principle. It still sucks for non-obvious types though: https://old.reddit.com/r/Python/comments/10zdidm/why_type_hi... Edit: Yes, one can sometimes go with Any, depending on the linter setup, but that's missing the point, isn't it?

The correct response to this is to figure what is the use case for your function: IE: add two numbers. Set the input and output as decimal and call it a day

Sure. Let me just quickly refactor Pytorch.

Re: Python developers are embracing type hints

#347

Post by knome »

coldtea wrote: post #324
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 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 anything that fit the shape the receiving code required. it allowed you to trivially create resource wrappers and change behaviors by providing alternate objects to existing mechanisms. if you wanted to provide a fake file that read from memory instead of an actual file, it was simple and correct.

the lack of protocols made hell of these patterns for years.

Re: Python developers are embracing type hints

#348

Post by blibble »

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)

Re: Python developers are embracing type hints

#349

Post by ninetyninenine »

JimDabell wrote: post #257
ninetyninenine wrote: post #166

Earlier quoted context omitted.

>WTF is “an anecdotal metric”‽ That just sounds like an evasive way to say “I want to make up numbers I can’t justify”. What I have to have scientific papers for every fucking opinion I have? The initial Parent post was an anecdotal opinion. Your post is an opinion. I can't have opinions here without citing a scientific paper that's 20 pages long and no is going to read but just blindly trust because it's "science"?…

> What I have to have scientific papers for every fucking opinion I have? No, but if you’re going to say things like “increase safety by roughly 2x” then if you can’t even identify the unit then you are misleading people. It’s absolutely fine to have an opinion. It’s not fine to make numbers up. > I'm confident my "anecdotal" metrics with I prefaced with "roughly" are "roughly" ballpark trueish. Okay, so if it’s 1.5×…

>No, but if you’re going to say things like “increase safety by roughly 2x” then if you can’t even identify the unit then you are misleading people.

So when I talk about multipliers I have to have a unit? What is the unit of safety? I can't say something like 2x more safe? I just have to say more safe? What if I want to emphasize that it can DOUBLE safety?

Basically with your insane logic people can't talk about productivity or safety or multipliers at the same time because none of these concepts have units.

Look I told YOU it's anecdotal, EVERYONE can read it. You're no longer "deceived" and no one else is.

>Okay, so if it’s 1.5×, 2.0×, or 2.5×… again, what metric? What unit are we dealing with?

If you don't have the capacity to understand what I'm talking about without me specifying a unit than I'll make one up:

I call it safety units. The amount of errors you catch in production. That's my unit: 1 caught error in prod in a year. For Untyped languages let's say you catch about 20 errors a year. With types that goes down to 10.

>It’s not a fact, it’s ridiculous. You genuinely believe that if somebody disagrees with you, it’s a fact that they lack knowledge and experience? It’s not even remotely possible for somebody to have an informed difference of opinion with you?

What? and you think all opinions are equal and everyone has the freedom to have any opinion they want and no one can be right or wrong because everything is just an opinion? Do all opinions need to be fully respected even though it's insane?

Like my example, if you have the opinion that eating horse shit is healthy, I'm going to make a judgement call that your opinion is WRONG. Lack of Typing is one of these "opinions"

Re: Python developers are embracing type hints

#350

Post by __MatrixMan__ »

scuff3d wrote: post #66
fnord77 wrote: post #40

Earlier quoted context omitted.

A entire class of bugs, wiped out by a thing called a "compiler". Gigahours of downtime and bug fixing globally prevented by a modest extra step up front. Great stuff.

I had someone say to me they preferred strict type checking in a Python linter over a statically typed language because they "don't like a build step"... Dudes it's literally just worse compilation with extra steps.

I'm in favor of partitioning the set of reasons it can fail to compile into separate checks with separate tools. Taming the zoo of tooling is extra work, but smaller more focused tools are easier to work with once you understand their relationship to their neighbors.

There's a world of difference between:

> I've been using a different type checker and I like it, you should try it

And

> I'd like to switch our project to a different compiler

The former makes for more nimble ecosystem.

Post reply on HN