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

131–140 of 166 posts

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

#131

Post by guappa »

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…

15 seconds after doing "man mypy": --disallow-any-expr

Less than it took you to write all that.

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

#132

Post by guappa »

Spivak wrote: post #41
MeetingsBrowser wrote: post #29

Earlier quoted context omitted.

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

pydantic does have @validate_call for this use-case.

Profile it and see how much slower it gets :)

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

#133

Post by guappa »

belmont_sup wrote: post #113
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?

As a Redditor said: > The standard VC business model is to invest in stuff that FAANG will buy from them one day. The standard approach is to invest in stuff that's enough of a threat to FAANG that they'll buy it to kill it, but this seems more like they're gambling on an acqui-hire in the future.

Why would they do that when they can just fork for free?

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

#134

Post by tnkuehne »

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 think I heard somewhere that they are working on other tools that only big enterprises need like a hosted private package registry.

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

#135

Post by rkangel »

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?

The announcement talked about selling services built on top of the tools: https://astral.sh/blog/announcing-astral-the-company-behind-...

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

#136

Post by stavros »

flanked-evergl wrote: post #100
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.

Also not creating custom, expressive Pydantic types and using nested dicts in places. Nested dicts suck, you never know what you're getting, and it's well worth the time converting them to classes.

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

#137

Post by sakesun »

lmz wrote: post #109
flakes wrote: post #93

Earlier quoted context omitted.

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

It's been there since Python v2.1 https://docs.python.org/release/2.1/lib/module-doctest.html

Here is the first announce of doctest I can find (1999) I think it's Python 1.5 time.

https://groups.google.com/g/comp.lang.python/c/DfzH5Nrt05E/m...

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

#138

Post by mejutoco »

stavros wrote: post #136
flanked-evergl wrote: post #100

Earlier quoted context omitted.

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.

Also not creating custom, expressive Pydantic types and using nested dicts in places. Nested dicts suck, you never know what you're getting, and it's well worth the time converting them to classes.

TypedDicts or data classes are both a good idea.

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

#139

Post by ramraj07 »

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…

Stupid is okay. _Nonsense_ is not. Your example was nonsense, it was absurd. The moment I saw the first example I was like, this should be add_ints and should only take ints.

Imagine I say "the human body is dumb! Here's an example: if I stab myself, it bleeds!" Like is that stupid or absurd?

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

#140

Post by ramraj07 »

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.

If you're supposedly good at software and you spent too long trying to make python work consider the possibility that you're not good at software?

Python has flaws and big ones at that, but there's a reason it's popular. Especially with tools like pydantic and fastapi and uv (and streamlit) you can do insane things in hours what would take weeks and months before. Not to mention how good AI is at generating code in these frameworks. I especially like typing using pydantic, any method is now able to dump and load data from files and dbs and you get extremely terse validated code. Modern IDEs also make quick work of extracting value even from partially typed code. I'd suggest you just open your mind up to imperfect things and give them a shot.

Post reply on HN