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

91–100 of 166 posts

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

#91

Post by dmurray »

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…

list[int | str] might usually be a mistake, but what about

my_list = [BarWidget(...), FooWidget(...)] ?

my_list.append(BazWidget(...))

my_list.append(7)

Wouldn't it be nice if the type checker could infer the type hint there, which is almost certainly intended to be list[Widget], and allow the first append and flag the second one?

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

#92

Post by mjr00 »

notatallshaw wrote: post #87
mjr00 wrote: post #77

Earlier quoted context omitted.

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…

As the author of that post, I'd like to point out the example was meant to be stupid. The purpose was to show different ideologies and expectations on the same code don't work, such as strict backwards compatibilities, duck typing, and strictly following linting or type hinting rules (due to some arbitrary enforcement). Although re-reading it now I wish I'd spent more than an evening working on it, it's full of issue…

> Following the general stupidness of the post: they are now unable to do that because a security consultant said they have to enable and can not break RUFF rule ANN401: https://docs.astral.sh/ruff/rules/any-type/

Okay, then your function which is extremely generic and needs to support 25 different use cases needs to have an insane type definition which covers all 25 use cases.

This isn't an indictment of the type system, this is an indictment of bad code. Don't write functions that support hundreds of input data types, most of which are unintended. Type systems help you avoid this, by the way.

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

#93

Post by flakes »

hathawsh wrote: post #86
flakes wrote: post #57

Earlier quoted context omitted.

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?

That concept has been formalized as part of the Python standard library. https://docs.python.org/3/library/doctest.html

Ah very nice! Did not realize this was a part of the standard library!

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

#94

Post by echelon »

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.

Not necessarily!

These are the strong vs weak, static vs dynamic axes.

You probably want strong, but dynamic typing. eg., a function explicitly accepts only a string and won't accept or convert a float into a string implicitly or magically.

You're free to bind or rebind variables to anything at any time, but using them in the wrong way leads to type errors.

JavaScript has weak dynamic typing.

Python has strong dynamic typing (though since types aren't annotated in function definitions, you don't always see it until a type is used in the wrong way at the leaves of the AST / call tree).

Ruby has strong dynamic typing, but Rails uses method_missing and monkey patching to make it weaker though lots of implicit type coercions.

C and C++ have weak static typing. You frequently deal with unstructured memory and pointers, casting, and implicit coercions.

Java and Rust have strong static typing.

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

#95

Post by dcreager »

boomer_joe wrote: post #75
dcreager wrote: post #34

Earlier quoted context omitted.

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?

The current plan is that they will remain separate tools, but will work together nicely if you are using both. For instance, we want to add type-aware and multi-file lints to ruff at some point down the line.

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

#96

Post by emptysea »

claytonjy wrote: post #79

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

Instagram built a linter with the ability to fix errors which is an improvement over flake8 & pylint: https://github.com/Instagram/Fixit

But Ruff is an even greater improvement over that

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

#97

Post by ckwalsh »

claytonjy wrote: post #79

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

Coming from a Meta background (not speaking on behalf of Meta):

"package/dependency management" - Everything is checked into a monorepo, and built with [Buck2](https://buck2.build/). There's tooling to import/update packages, but no need to reinvent pip or other package managers. Btw, Buck2 is pretty awesome and supports a ton of languages beyond python, but hasn't gotten a ton of traction outside of Meta.

"linting, formatting" - [Black](https://github.com/psf/black) and other public ecosystem tooling is great, no need to develop internally.

"why is type checking the exception" - Don't know about Astral, but for Meta / Google, most everyone else doesn't design for the scale of their monorepos. Meta moved from SVN to Git to Mercurial, then forked Mercurial into [Sapling](https://sapling-scm.com/) because simple operations were too slow for the number of files in their repo, and how frequently they receive diffs.

There are obvious safety benefits to type checking, but with how much Python code Meta has, mypy is not an option - it would take far too much time / memory to provide any value.

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

#98

Post by maleldil »

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 think it's fine to have those if it makes API design and better. In my mind, there's "code you should write" and there's "code only libraries should write".

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

#99

Post by move-on-by »

whyho wrote: post #62

Astral tooling is great and brings new energy into python land but what is the long game of all astral projects? Integrate them into python natively? Be gone in 5 years and leave unmaintained tooling behind? Rug pull all of us with a subscription?

I don’t think any of these questions are specific to Astral and can be applied to pretty much any project. ‘Be gone in 5 years and leave unmaintained tooling’ seems particularly plausible with regard to Facebook’s tooling.

Use any of them at your own risk I suppose.

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

#100

Post by flanked-evergl »

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…

As someone who has been writing python for years the worst mistake I have ever seen people make is not add type hints and not using a type checker.
Post reply on HN