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

1–10 of 166 posts

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

#2

Post by senkora »

> 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 dynamic codebases, it seems like the right way to do gradual typing.

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

#3

Post by yoyohello13 »

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…

Unless you're doing greenfield, gradual typing is really the only way. I've incorporated type hinting in several legacy Python code bases with mypy and really the only sensible way is to "opt-in" one module at a time. If pyrefly doesn’t support that I think its use will be pretty limited. Unless maybe they are going for the llm code gen angle. I could see a very fast and strict type checker being useful for llm generating python scripts.

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

#5

Post by RandomBK »

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…

It reminds me of the early days of Typescript rollout, which similarly focused on a smooth on-boarding path for existing large projects.

More restrictive requirements (ie `noImplicitAny`) could be turned on one at a time before eventually flipping the `strict` switch to opt in to all the checks.

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

#7

Post by thelastbender12 »

paddy_m wrote: post #4

I hope some typechecker starts doing serious supported notebook integration. And integration for live coding, not just a batch script to statically check your notebook. Finding errors with typing before running a 1-60 minute cell is a huge win.

Do you use Jupyter notebooks in VSCode? It uses the same pylance as regular python files, which actually gets annoying when I want to write throwaway code.

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

#8

Post by rendaw »

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 issue when I tried mypy - there was no way to actually guarantee that you were getting any protection from types. A way to assert "no graduality to this file, it's fully typed!" is critical, but gradual typing is not just about migrating but also about the crazy things you can do in dynamic languages and being terrified of false positives scaring away the people who didn't value static typing in the first place. Maybe calling it "soft" typing would be clearer.

I think gradual typing is an anti-pattern at this point.

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

#9

Post by dgroshev »

I really wish they get first class Django support. Sadly, its ORM architecture is impossible to type and impossible to change now. Django is one of the most important use cases for Python, having fast full type checking with Django is a dream, but it does require some special casing from the type checker.
Post reply on HN