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

121–130 of 166 posts

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

#121

Post by bjackman »

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.

I think you're forgetting how easy type annotation is.

I occasionally spend like 2h working on some old python code. I will spend say 15 minutes of that time adding type annotations (sometimes requires some trivial refactoring). This has an enormous ROI, the cost is so low and the benefit is so immediate.

In these cases migrating code to a proper language and figuring out interop is not on my radar, it would be insane. So having the option to get some best-effort type safety is absolutely fantastic.

I can definitely see your point, it's a useful analysis for projects under heavy development. But if you have a big Python codebase that basically just works and only sees incremental changes, adding type annotations is a great strategy.

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

#122

Post by suspended_state »

fastasucan wrote: post #80
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 e…

Indeed, I'm not a regular Python practitioner. I had to use it from time to time because it's the language chosen by the tools I happened to use at that time, like Blender, or Django. In the former case, it wasn't very enjoyable (which says a lot about my skills in that area, or rather lack thereof), while in the latter case I found it quite likeable. So that's my background as far as python goes.

I must admit that I largely prefer static typing, which is why I got interested in that article. It's true that trying to shoehorn this feature in the Python ecosystem is an uphill battle: there's a lot of good engineering skill spent on this.

Perhaps there's a connection to make between this situation and an old theorem about incompleteness?

https://copilot.microsoft.com/shares/2LpT2HFBa3m6jYxUhk9fW

(was generated in quick mode, so you might want to double check).

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

#123

Post by guappa »

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 do that you need to compile, which means you can't just distribute a text file with your python program. You need a build infrastructure for every python version, every architecture and every OS.

Have fun with that!

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

#124

Post by rtpg »

Epa095 wrote: post #120
dcreager wrote: post #24

Earlier quoted context omitted.

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

So, how does that relate to this quote from the article? >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. It seems like `ty`'s current behaviour is compatible with this, but changing it won't…

You could have a `list[int | str]` but then you need to check the type of the elements in the list on usage to see if they are `int` or `str` (if you are actually trying to put the elements into a place that requires an `int` or requires a `str` but wouldn't accept an `int | str`...).

If your code doesn't do that then your program isn't well typed according to Python's typing semantics... I think.

So you can have lists of multiple types, but then you get consequences from that in needing type guards.

Of course you still have stuff like `tuple[int, int, int, str]` to get more of the way there. Maybe one day we'll get `FixedList[int, int, int, str]`....

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

#125

Post by rtpg »

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.

I don't understand this point at all. I've worked on Django codebases which have a huge set of typing problems... and while it's not 100% I get a lot of value out of type checking.

You annotate enough functions and you get a really good linter out of it!

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

#126

Post by rtpg »

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…

In code where you really want to have these guarantees you turn on errors lke "no implicit any" in mypy and tighten the restrictions on the files you care about.

You still have the "garbage in/garbage out" problem on the boundaries but at the very least you can improve confidence. And if you're hardcore... turn that on all over, turn off explicit Any, write wrappers around all of your untyped dependencies etc etc. You can get what you want, just might be a lot of work

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

#127

Post by mzl »

hu3 wrote: post #68
davedx wrote: post #67

Earlier quoted context omitted.

Unfortunately with us being in the middle of the AI hype cycle, everyone and their dog is currently busy migrating to python.

I don't see why AI hype means more Python code. State of the art AI models are all closed source and accessible through an API anyways. APIs that any language can easily access. AAa for AI model development in itself, yes it's mostly Pyython, but niche.

I think you are underestimating the massive amounts of Python code that is built around these things. Also, a lot of businesses are not really interested in using an API for an LLM, instead they will modify and fine-tune their own models and deploy in their own data-centers (virtual or physical), and that means even more Python code.

Sure, a system that only relies on token factory LLM APIs can be written in any language, but that is not the full width and breadth of the AI hype.

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

#128

Post by rtpg »

MeetingsBrowser wrote: post #18
dgroshev wrote: post #9

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.

What makes the Django ORM impossible to type check?

It's possible to write a Django typecheck shim using descriptors. There's some annoying stuff on the edges though, and for example if you are changing up fields in `__init__` then those aren't going to show up in your types.

Ultimately you can get typing for the usual cases, but it won't be complete because you can outright change the shape of your models in Django at runtime (actions that aren't type safe of course)

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

#129

Post by guappa »

kstrauser wrote: post #66
kccqzy wrote: post #60

Earlier quoted context omitted.

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

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…

I never understood why pydantic reimplemented attrs, but doing it much slower, instead of just using attrs.

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

#130

Post by guappa »

bbkane wrote: post #116
kccqzy wrote: post #60

Earlier quoted context omitted.

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

You should try Go!

It should be banned by the geneva convention.
Post reply on HN