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

Post by belmont_sup » Wed, May 28, 2025, 3:01 AM UTC

MeetingsBrowser wrote: post #29

belmont_sup wrote: post #16

Earlier quoted context omitted.

Responding to your gradual typing anti-pattern bit: Agree that dynamic language behaviors can be extreme but it’s also easy to get into crazy type land. Putting aside a discussion of type systems, teams can always add runtime checks like pydantic to ensure your types match reality. Sorbet (Ruby typechecker) does this where it introduces a runtime checks on signatures. Similarly in ts, we have zod.

> teams can always add runtime checks like pydantic to ensure your types match reality. That's the problem with bugs though, there's always something that could have been done to avoid it =) Pydantic works great in specific places, like validating user supplied data, but runtime checks as a replacement for static type checkers are not really feasible. Every caller would need to check that the function is being called…

Post by __mharrison__ » Wed, May 28, 2025, 3:32 AM UTC

flakes wrote: post #57

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…

Really loving those markdown style tests. I think it's a really fantastic idea that allows the tests to easily act as documentation too. Can you explain how you came up with this solution? Rust docs code-examples inspired?

Post by bbkane » Wed, May 28, 2025, 4:24 AM UTC

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…

Post by thom » Wed, May 28, 2025, 5:59 AM UTC

Post by Epa095 » Wed, May 28, 2025, 6:34 AM UTC

dcreager wrote: post #24

kuratkull wrote: post #11

> my_list = [1, 2, 3] > pyrefly, mypy, and pyright all assume that my_list.append("foo") is a typing error, even though it is technically allowed (Python collections can have multiple types of objects!) > If this is the intended behavior, ty is the only checker that implicitly allows this without requiring additional explicit typing on my_list. EDIT: I didn't intend my comment to be this sharp, I am actually rooting…

> I am strongly against ty behaviour here. [ty developer here] Please note that ty is not complete! In this particular example, we are tripped up because ty does not do anything clever to infer the type of a list literal. We just infer `list[Unknown]` as a placeholder, regardless of what elements are present. `Unknown` is a gradual type (just like `Any`), and so the `append` call succeeds because every type is assign…

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