Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

blog.edward-li.com

Post reply on HN
Print view View original

61–70 of 166 posts

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#61

Post by tclancy »

rendaw wrote: post #8
senkora wrote: post #2

> ty, on the other hand, follows a different mantra: the gradual guarantee. The principal idea is that in a well-typed program, removing a type annotation should not cause a type error. In other words: you shouldn’t need to add new types to working code to resolve type errors. The gradual guarantee that Ty offers is intriguing. I’m considering giving it a try based on that. With a language like Python with existing d…

Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. Even in critical code you thought was fully typed. Where you mistakenly introduce a type bug and due to some syntax or inference limits the type checker unexpectedly loses the plot and tells you confidently "no problems in this file!" I get where they're coming from, but the endgame was a huge issu…

Yeah, I’m torn because, in my experience, gradual typing means the team members who want it implement it in their code and the others do not or are very lax in their typing. Some way of swapping between gradual and strict would be nice.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#63

Post by LoganDark »

merksoftworks wrote: post #51

I'd like to experiment with writing a reflection based dynamic type annotator for one of these. Just as a toy. Imagine a module which monkey patches every function, class in the parent module it is loaded into, then reflects on the arguments at run time slowly building up a database of expected type signatures. The user would then pick through the deltas approving what made sense.

This is a neat idea, but for large systems it could take a long time to fully exercise every code path with all possible input data. (If this sounds way too excessive, that's because normal people don't do this.)

Unless you mean something like record prod for a few weeks to months, similar to how Netflix uses eBPF (except they run it all the time).

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#64

Post by davedx »

dcreager wrote: post #27

[ty developer here] We are happy with the attention that ty is starting to receive, but it's important to call out that both ty and pyrefly are still incomplete! (OP mentions this, but it's worth emphasizing again here.) There are definitely examples cropping up that hit features that are not yet implemented. So when you encounter something where you think what we're doing is daft, please recognize that we might have…

I am very interested in both of these. Coming from the TypeScript world I'm really interested in the different directions (type inference or not, intersections and type narrowing...). As a Python developer I'm wearily resigned to there being 4+ python type checkers out there, all of which behave differently. How very python...

Following these projects with great interest though. At the end of the day, a good type checker should let us write code faster and more reliably, which I feel isn't yet the case with the current state of the art of type checking for python.

Good luck with the project!

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#65

Post by pydry »

dcreager wrote: post #31
rendaw wrote: post #8

Earlier quoted context omitted.

Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. Even in critical code you thought was fully typed. Where you mistakenly introduce a type bug and due to some syntax or inference limits the type checker unexpectedly loses the plot and tells you confidently "no problems in this file!" I get where they're coming from, but the endgame was a huge issu…

> Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. Even in critical code you thought was fully typed. Where you mistakenly introduce a type bug and due to some syntax or inference limits the type checker unexpectedly loses the plot and tells you confidently "no problems in this file!" This is a good point, and one that we are taking into account…

You could give a score to different folders or files to indicate a level of "type certainty" and allow people to define failure thresholds.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#66

Post by kstrauser »

kccqzy wrote: post #60
suspended_state wrote: post #49

I am not well versed in python programming, this is just my opinion as an outsider. For anyone interested in using these tools, I suggest reading the following: https://www.reddit.com/r/Python/comments/10zdidm/why_type_hi... That post should probably be taken lightly, but I think that the goal there is to understand that even with the best typing tools, you will have troubles, unless you start by establishing good pr…

> Python, AFAIK, has many features, a very permissive runtime, and perhaps (not unlike C++) only some limited subset should be used at any time to ensure that the code is manageable. Unfortunately, that subset is probably different depending on who you ask, and what you aim to do. I'll get started on the subset of Python that I personally do not wish to use in my own codebase: meta classes, descriptors, callable obje…

There's a time and a place for each of them:

* Meta classes: You're writing Pydantic or an ORM.

* Descriptors: You're writing Pydantic or an ORM.

* Callable objects: I've used these for things like making validators you initialize with their parameters in one place, then pass them around so other functions can call them. I'd probably just use closures if at all possible now.

* object.__new__: You're writing Pydantic or an ORM.

* Name mangling: I'm fine with using _foo and __bar where appropriate. Those are nice. Don't ever, ever try to de-mangle them or I'll throw a stick at you.

* self.__dict__: You're writing Pydantic or an ORM, although if you use this as shorthand for "doing things that need introspection", that's a useful skill and not deep wizardry.

Basically, you won't need those things 99.99% of the time. If you think you do, you probably don't. If you're absolutely certain you do, you might. It's still good and important to understand what they are, though. Even if you never write them yourself, at some point you're going to want to figure out why some dependency isn't working the way you expected, and you'll need to read and know what it's doing.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#67

Post by davedx »

mhh__ wrote: post #59
suspended_state wrote: post #49

I am not well versed in python programming, this is just my opinion as an outsider. For anyone interested in using these tools, I suggest reading the following: https://www.reddit.com/r/Python/comments/10zdidm/why_type_hi... That post should probably be taken lightly, but I think that the goal there is to understand that even with the best typing tools, you will have troubles, unless you start by establishing good pr…

At this point I'm fairly convinced that the effort one would spend trying to typecheck a python program is better spent migrating away from python into a language that has a proper type system, then using interop so you can still have the bits/people that need python be in python. Obviously that isn't always possible but you can spend far too long trying to make python work.

Unfortunately with us being in the middle of the AI hype cycle, everyone and their dog is currently busy migrating to python.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#68

Post by hu3 »

davedx wrote: post #67
mhh__ wrote: post #59

Earlier quoted context omitted.

At this point I'm fairly convinced that the effort one would spend trying to typecheck a python program is better spent migrating away from python into a language that has a proper type system, then using interop so you can still have the bits/people that need python be in python. Obviously that isn't always possible but you can spend far too long trying to make python work.

Unfortunately with us being in the middle of the AI hype cycle, everyone and their dog is currently busy migrating to python.

I don't see why AI hype means more Python code.

State of the art AI models are all closed source and accessible through an API anyways. APIs that any language can easily access.

AAa for AI model development in itself, yes it's mostly Pyython, but niche.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#69

Post by adamors »

davedx wrote: post #67
mhh__ wrote: post #59

Earlier quoted context omitted.

At this point I'm fairly convinced that the effort one would spend trying to typecheck a python program is better spent migrating away from python into a language that has a proper type system, then using interop so you can still have the bits/people that need python be in python. Obviously that isn't always possible but you can spend far too long trying to make python work.

Unfortunately with us being in the middle of the AI hype cycle, everyone and their dog is currently busy migrating to python.

I’d be surprised if _anyone_ is migrating server code to Python because of AI.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#70

Post by kccqzy »

kstrauser wrote: post #66
kccqzy wrote: post #60

Earlier quoted context omitted.

> Python, AFAIK, has many features, a very permissive runtime, and perhaps (not unlike C++) only some limited subset should be used at any time to ensure that the code is manageable. Unfortunately, that subset is probably different depending on who you ask, and what you aim to do. I'll get started on the subset of Python that I personally do not wish to use in my own codebase: meta classes, descriptors, callable obje…

There's a time and a place for each of them: * Meta classes: You're writing Pydantic or an ORM. * Descriptors: You're writing Pydantic or an ORM. * Callable objects: I've used these for things like making validators you initialize with their parameters in one place, then pass them around so other functions can call them. I'd probably just use closures if at all possible now. * object.__new__: You're writing Pydantic…

> Basically, you won't need those things 99.99% of the time

That's kind of my point. If you don't need a language feature 99.99% of the time perhaps it is better to cut it out from your language altogether. Well unless your language is striving to have the same reputation as C++. In Python's case here's a compromise: such features can only be used in a Python extension in C code, signifying their magic nature.

Post reply on HN