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

101–110 of 166 posts

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

#101

Post by ramses0 »

eternityforest wrote: post #39
dcreager wrote: post #31

Earlier quoted context omitted.

> 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!" This is a good point, and one that we are taking into account…

Could there ever be a flag to turn off the gradual guarantee and get stricter behavior?

"use strict";

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

#102

Post by flanked-evergl »

librasteve wrote: post #85

it is sad to see how painful typed python is … i prefer a language where (gradual) types were designed infrom the get go … https://raku.org

As someone who has added type hints to two huge code bases that had nine. It's not that painful. Something much more painful is realizing the code base you are adding type hints to is irreconcilably bugged by design, which would not have been possible had type checking been used.

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

#103

Post by shoeb00m »

luoc wrote: post #21
ameliaquining wrote: post #15

Earlier quoted context omitted.

I don't think it's optimizing for beginner-level code, I think it's optimizing for legacy code. Introducing a type checker to a large existing untyped codebase is a big lift, but becomes less of one if almost all existing code is accepted.

Well then support an option to enable that kind behaviour? Make it an explicit decision by the devs. I think running in a type error and then adding an exception to your config is safer than silently pass and only learn about the mixed types in a production bug

I think this should be handled by a type assisted linter not typechecker.

Imo a type checker in a dynamic language should is primarily there to avoid runtime errors. In a list with multiple types the typechecker should instead force you to check the type before using an element in that list.

If you want static types python is the wrong language

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

#104

Post by mdaniel »

tadfisher wrote: post #74
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…

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

Please no

  let { (*>), (

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

#105

Post by mdaniel »

J_Shelby_J wrote: post #88
mhh__ wrote: post #59

Earlier quoted context omitted.

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.

Six month into learning to build a modern python app, with linters, type systems, tests, venvs, package managers, etc… I realized that the supposed difficulty of rust is drastically less than coming to speed and then keeping up with the python “at scale” ecosystem.

My strong suspicion is that such a story depends a great deal upon the personalities of the developers much more than any {tool chaos + type chaos} --- {new syntax + lifespan annotations} spectrum

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

#106

Post by djrj477dhsnv »

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.

What kind of codebases cause performance problems?

I've been using pyright with neovim for years and have never experienced any kind of noticeable lag.

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

#107

Post by ijustlovemath »

dcreager wrote: post #24
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…

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

Have you all looked at how Pyrefly does it, or are your methods incompatible?

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

#108

Post by ijustlovemath »

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?

They'll most likely pursue some sort of business source licensing, where you will not be allowed to deploy apps in production using their tooling without the business paying some kind of subscription. I understand that none of their existing products fit this use case, but it will probably be a similar approach. VCs are not charities.

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

#109

Post by lmz »

flakes wrote: post #93
hathawsh wrote: post #86

Earlier quoted context omitted.

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!

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

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

#110

Post by the_af »

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…

But there was a conceivable way (maybe not in Python) to make a `slow_add` function very generic, yet only be defined over structures where any conceivable `+` operation is defined.

You just have to say the type implements Semigroup.

Yes, this would work if the arguments are lists, or integers, or strings. And it won't pass the typecheck for arguments that are not Semigroups.

It may not work with Python, but only because it's designers weren't initially interested in typechecking.

Post reply on HN