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

161–166 of 166 posts

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

#161

Post by N1H1L »

I have a problem with Python's `Optional` type. For example for this following code:

   from typing import Optional, Union
   def square(
      a: Union[int, float], 
      b: Optional[int] = 2
   ) -> float:
      c = a**b
      return c
Many type checkers throw an error because `Optional[int]` actually means `int | None` and you cannot square an `int` or a `float` with a `None`. Is there any plans for *ty* around this?

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

#162

Post by _carljm »

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…

There are ways to type invariant generics more precisely that still meet the gradual guarantee. E.g.:

  x = []  # list[Unknown]
  x.append(A())  # list[Unknown | A]
  takes_list_of_a_or_b(x)  # list[A | B]
We haven't decided yet if this is what we want to do, though. It's also possible that we may decide to compromise on the gradual guarantee in this area. It's not an ironclad rule for us, just something we're considering as a factor.

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

#163

Post by dcreager »

N1H1L wrote: post #161

I have a problem with Python's `Optional` type. For example for this following code: from typing import Optional, Union def square( a: Union[int, float], b: Optional[int] = 2 ) -> float: c = a**b return c Many type checkers throw an error because `Optional[int]` actually means `int | None` and you cannot square an `int` or a `float` with a `None`. Is there any plans for *ty* around this?

I think that's a genuine error, since as you say, `None` is a possible value for `b` according to your signature.

To handle this you would need to use "narrowing" to separately handle the case where `b` is `None`, and the case where it is not:

  def square(a: Union[int, float], b: Optional[int] = 2) -> float:
      if b is None:
          return 0
      else:
          c = a**b
          return c
https://play.ty.dev/97fe4a09-d988-4cc3-9937-8822e292f8d1

(This is not specific to ty, that narrowing check should work in most Python type checkers.)

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

#164

Post by merksoftworks »

LoganDark wrote: post #63
merksoftworks wrote: post #51

I'd like to experiment with writing a reflection based dynamic type annotator for one of these. Just as a toy. Imagine a module which monkey patches every function, class in the parent module it is loaded into, then reflects on the arguments at run time slowly building up a database of expected type signatures. The user would then pick through the deltas approving what made sense.

This is a neat idea, but for large systems it could take a long time to fully exercise every code path with all possible input data. (If this sounds way too excessive, that's because normal people don't do this.) Unless you mean something like record prod for a few weeks to months, similar to how Netflix uses eBPF (except they run it all the time).

I think my main use case would be to run it on unit tests, and then to provide a human-in-the-loop way to slowly hydrate small to medium sized code bases with types. Maybe progressive refactor tools aren't something anyone actually wants to use or maintain, because I just don't see them around that much.

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

#165

Post by noisy_boy »

guappa wrote: post #133
belmont_sup wrote: post #113

Earlier quoted context omitted.

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?

They also get a shot at the engineers who wrote the product.

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

#166

Post by mzl »

hu3 wrote: post #148
mzl wrote: post #127

Earlier quoted context omitted.

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

> 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 You realize model training cost millions right? "a lot of businesses" doesn't pass sniff test here. I'm not even counting the large swaths of data required to train. And the expensive specialists. And then you'll have to retrain outdated models…

SOTA LLM model training costs a lot, yes. But fine-tuning and training of smaller models is a lot cheaper.

I've trained useful vision-models that delivered business value for industrial applications on a MacBook overnight.

Post reply on HN