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

71–80 of 166 posts

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

#71

Post by dcreager »

zem wrote: post #42
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…

surfacing revealed types as `@TODO` made me laugh, but thinking about it it's actually a pretty neat touch!

It really helps in our mdtests, because then we can assert that not-implemented things are currently wrong but for the right reasons!

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

#72

Post by tadfisher »

julienfr112 wrote: post #53
echelon wrote: post #48

Earlier quoted context omitted.

Totally orthogonal question, but since you're deep in that side of Rust dev - The subject of a "scripting language for Rust" has come up a few times [1]. A language that fits nicely with the syntax of Rust, can compile right alongside rust, can natively import Rust types, but can compile/run/hot reload quickly. Do you know of anyone in your network working on that? And modulus the syntax piece, do you think Python co…

Most of the time, you want the type to be dynamic in a scripting langage, as you don't want to expose the types to the user. With this in mind, rhai and rune are pretty good. On the python front, there was also the pyoxidizer thing, put it seems dead.

If the language has types at all, they're exposed to the user, even if the time of exposure is a runtime failure. I suspect you want inferred types, which can be had in statically-typed languages.

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

#73

Post by vintagedave »

maleldil wrote: post #46
vintagedave wrote: post #44

What was not immediately obvious to me (but should have been) is that these are dev-time type checkers -- I think. (I think, both from from the github descriptions which focus heavily on editing, and from the article.) That's really useful because type inference is lacking, to me, in-editor. I tend to ask Copilot: 'add type annotations'. So in complement to this can I share my favorite _run-time_ type checker? Bearty…

beartype is great, but I only find it useful at the edges. Runtime checks aren't needed if you have strict typing throughout the project. On a gradually-typed codebase, you can use beartype (e.g. is_bearable) to ensure the data you're ingesting has the proper type. I usually use it when I'm dealing with JSON types.

Why isn’t it necessary? Do you mean that with edit-time type checking, you can catch all errors, so no need for runtime verification the edit-time type decls match?

What about interacting with other libraries?

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

#74

Post by tadfisher »

echelon wrote: post #48
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…

Totally orthogonal question, but since you're deep in that side of Rust dev - The subject of a "scripting language for Rust" has come up a few times [1]. A language that fits nicely with the syntax of Rust, can compile right alongside rust, can natively import Rust types, but can compile/run/hot reload quickly. Do you know of anyone in your network working on that? And modulus the syntax piece, do you think Python co…

There's Gluon, which doesn't share Rust's syntax but does have a Hindley-Milner-based type system and embeds pretty seamlessly in a Rust program.

https://github.com/gluon-lang/gluon

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

#75

Post by boomer_joe »

dcreager wrote: post #34
kombine wrote: post #19

Are any of these already useful as LSPs for code editors such as Neovim? I run pyright in my Neovim config but I could certainly use something faster.

ty is definitely not ready to be a pyright replacement yet. But it is usable as an LSP for simple things like go to definition, and deeper LSP features are on the roadmap for the eventual beta and GA releases. https://github.com/astral-sh/ty/blob/main/docs/README.md#oth...

What's the plan for ruff? Will it be part of ty one day?

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

#76

Post by orbital223 »

kccqzy wrote: post #70
kstrauser wrote: post #66

Earlier quoted context omitted.

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.

I don't need my car's airbags 99.99% of the time.

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

#77

Post by mjr00 »

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…

The top comment in that post shuts down the whole nonsense pretty quickly and firmly:

> If you have a super-generic function like that and type hinting enforced, you just use Any and don't care about it.

It's a stupid example, but even within the context of a `slow_add` function in a library: maybe the author originally never even thought people would pass in non-numeric values, so in the next version update instead of a hardcoded `time.sleep(0.1)` they decide to `time.sleep(a / b)`. Oops, now it crashes for users who passed in strings or tuples! If only there were a way to declare that the function is only intended to work with numeric values, instead of forcing yourself to provide backwards compatibility for users who used that function in unexpected ways that happened to work.

IMO: for Python meant to run non-interactively with any sort of uptime guarantees, type checking is a no-brainer. You're actively making a mistake if you choose to not add type checking.

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

#78

Post by mixmastamyk »

kccqzy wrote: post #70
kstrauser wrote: post #66

Earlier quoted context omitted.

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.

A lot of people want pydantics and orms.

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

#79

Post by claytonjy »

for decades, big tech contributed relatively little in the way of python ecosystem tooling. There’s Facebooks Pyre, but that’s about it. Nothing for package/dependency management, linting, formatting, so folks like those at Astral have stepped up to fill the gap.

why is type checking the exception? with google and facebook and astral all writing their own mypy replacements, i’m curious why this space is suddenly so busy

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

#80

Post by fastasucan »

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…

Can you share a little bit about what makes you form opinions when you are not even using the language? I think its fascinating how especially discussions about typing makes people shake their fists against a language they don't even use - and like your post make up some contrived example.

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

Like - what makes you think that python developers doesn't understand stuff about Python, when they are actively using the language as opposed to you?

Post reply on HN