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

461–470 of 581 posts

Re: Python developers are embracing type hints

#461

Post by [deleted] »

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

[deleted]

Re: Python developers are embracing type hints

#462

Post by ndriscoll »

amluto wrote: post #342
thr0w4w4y1337 wrote: post #221

Earlier quoted context omitted.

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.

Co- means with. Contra- means against. There are lots of words with these prefixes you could use to remember (cooperate, contradict, etc.).

Re: Python developers are embracing type hints

#463

Post by thrance »

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…

For this very specific example, isn't there something like "Indexable[int]"?

Re: Python developers are embracing type hints

#464

Post by aunderscored »

JackSlateur wrote: post #236
aunderscored wrote: post #155

Earlier quoted context omitted.

Without significant language changes, this is not possible. While your code may be typed as an int, I can simply redefine what int means. I can also modify the code in your method.

Yes I guess it would work with the ongoing jit work, which (as far as I understood..) run the code "as usual", then notice that a specific variable is always a dict (or whatever). Then it patches the code to run the dict-optimized code by default (and fallback to the generic code if, somehow, the variable is no longer a dict). With typing, the generic code could be avoided altogether. The algorithm would be: - notice…

There are already some bits of this with specific bytecode and the upcoming jit, it's not using annotations at all though

Re: Python developers are embracing type hints

#465

Post by nurettin »

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…

Why not do Indexable = Any and pass that? Even if it doesn't help your jit or the IDE, at least it is more explicit than

    def lol(blarg):  # types? haha you wish. rtfc you poor sod. Pytharn spirit ftw!!!
        ...
        return omg[0].wtf["lol freedom"].pwned(Good.LUCK).figuring * out

Re: Python developers are embracing type hints

#466

Post by Syntaf »

scuff3d wrote: post #43
imron wrote: post #29

Earlier quoted context omitted.

I too would much rather work in a statically typed language, but sometimes you have to work with what you’ve got. These systems are part of the core banking platform for a bank so I’d rather some initial developer friction over runtime incidents. And I say initial friction because although developers are sometimes resistant to it initially, I’ve yet to meet one who doesn’t come to appreciate the benefits over the cou…

I'm not opposed to type hints, I use them everywhere. It's specially the strict linting. But it's a fair point. If you truly have no option it's better then absolutely nothing. I really wish people would stop writing mission critical production code in Python.

I feel like it's more often a result of suffering from success that leads to these situations, rather than a lack of foresight to begin with.

For example I work on a python codebase shared by 300+ engineers for a popular unicorn. Typing is an extremely important part of enforcing our contracts between teams within the same repository. For better or for worse, python will likely remain the primary language of the company stack.

Should the founder have chosen a better language during their pre-revenue days? Maybe, but at the same time I think the founder chose wisely -- they just needed something that was _quick_ (Django) and capable of slapping features / ecosystem packages on top of to get the job done.

For every successful company built on a shaky dynamic language, there's probably x10 more companies that failed on top of a perfect and scalable stack using static languages.

Re: Python developers are embracing type hints

#467

Post by ninetyninenine »

AlienRobot wrote: post #460
ninetyninenine wrote: post #88

Earlier quoted context omitted.

You're actually missing the benefit of this. It's actually a feature. With python, because types are part of python itself, they can thus be programmable. You can create a function that takes in a typehint and returns a new typehint. This is legal python. For example below I create a function that dynamically returns a type that restricts a Dictionary to have a specific key and value. from typing import TypedDict def…

That's horrible. Nobody needs imperative metaprogramming for type hints. In fact, it would be absolute insanity for a typechecker to check this because it would mean opening a file in VS code = executing arbitrary python code. What stops me from deleting $HOME inside make_typed_dict? TypeScript solves this with its own syntax that never gets executed by an interpreter because types are striped when TS is compiled to…

>VS code = executing arbitrary python code. What stops me from deleting $HOME inside make_typed_dict?

Easy make IO calls illegal in the type checker. The type checker of course needs to execute code in a sandbox. It won't be the full python language. Idris ALREADY does this.

Re: Python developers are embracing type hints

#468

Post by ninetyninenine »

bgwalter wrote: post #351
ninetyninenine wrote: post #142

Earlier quoted context omitted.

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

The syntax is a monstrosity. You can also extract a proven OCaml program from Coq and Coq has a beautiful syntax. If you insist on the same language for specifying types, some Lisp variants do that with a much nicer syntax. Python people have been indoctrinated since ctypes that a monstrous type syntax is normal and they reject anything else. In fact Python type hints are basically stuck on the ctypes level syntax wi…

That's just a sugar thing. Yeah it can get a bit more verbose.

Re: Python developers are embracing type hints

#469

Post by ninetyninenine »

JimDabell wrote: post #398
ninetyninenine wrote: post #349

Earlier quoted context omitted.

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

Take a step back and look at what you are saying: > If someone disagrees with me (on this specific topic), it absolutely doesn't mean they are a junior. It means they lack knowledge and experience. This is a fact. You think it’s impossible for anybody to have an informed opinion that disagrees with yours. You literally think yours is the only possible valid opinion. If that doesn’t set off big warning bells in your h…

>You think it’s impossible for anybody to have an informed opinion that disagrees with yours. You literally think yours is the only possible valid opinion. If that doesn’t set off big warning bells in your head, you are in dire need of a change in attitude.

I mean do you think we should have a fair and balanced discussion about the merits of child molestation and rape? We should respect other people's opinion and not tell them they are wrong if there opinion differs? That's what I think of your opinion. I think your opinion is utterly wrong, and I do think my opinion is the valid opinion.

Now that doesn't mean I disrespect your opinion. That doesn't mean your not allowed to have a different opinion. It just means I tell you straight up, you're wrong and you lack experience. You're free to disagree with that and tell me the exact same thing. I'm just blunt, and I welcome you to be just as blunt to me. Which you have.

The thing I don't like about you is that you turned it into discussion about opinions and the nature of holding opinions. Dude. Just talk about the topic. If you think I'm wrong. Tell me straight up. Talk about why I'm wrong. Don't talk about my character and in what manner I should formulate opinions and what I think are facts.

>This conversation is not productive, let’s end it.

I agree let's end it. But let's be utterly clear. YOU chose to end it with your actions by shifting the conversation into saying stuff like "you literally think yours is the only possible opinion." Bro. All you need to do is state why you think my opinion is garbage and prove it wrong. That's the direction of the conversation, you ended it by shifting it to a debate on my character.

Re: Python developers are embracing type hints

#470

Post by loglog »

MangoToupe wrote: post #377
watwut wrote: post #115

Earlier quoted context omitted.

> Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, No they dont. There is nothing about types that would make incremental develpment harder. They keep having the same benefits when being incremental.

> There is nothing about types that would make incremental develpment harder. Oh, please, this is either lack of imagination or lack of effort to think. You've never wanted to test a subset of a library halfway through a refactor?

Yes, type checkers are very good at tracking refactoring progress. If it turns out that you can proceed to test some subset, then congratulations, you found a new submodule.
Post reply on HN