Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyrefly: Python type checker and language server in Rust

pyrefly.org

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Pyrefly: Python type checker and language server in Rust

#71

Post by notatallshaw »

eqvinox wrote: post #69
notatallshaw wrote: post #63

Earlier quoted context omitted.

The standard library does not directly include type hints, they are stored in typeshed: https://github.com/python/typeshed You can take a look yourself if you think some of them are wrong: https://github.com/python/typeshed/tree/main/stdlib/asyncio The advantage is type hints can be fixed without needing to release a new version of Python. The disadvantage is there's a lot of code in the standard library that doesn't…

> You can take a look yourself if you think some of them are wrong: https://github.com/python/typeshed/tree/main/stdlib/asyncio Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't: ERROR Argument `Future[list[BaseException | Any]]` is not assignable to parameter `future` with type `Awaitable[tuple[Any]]` in function `asyncio.events.AbstractEventLoo…

> Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't:

> …where is it even puling "tuple[Any]" from…

Perhaps it's a bug in pyrefly, perhaps mypy or pyrefly is able to infer something about the types that the other isn't. I would strongly suggest checking their issues page, and if not seeing a report already report it yourself.

While there is an ongoing push to more consistently document the typing spec: https://typing.python.org/. It does not actually cover all the things you can infer from type hints, and different type hint checkers have decided to take different design choices compared to mypy and will produce different errors even in the most ideal situation.

This is one of the reasons why I am waiting for these libraries to mature a little more.

Re: Pyrefly: Python type checker and language server in Rust

#72

Post by wiseowise »

f311a wrote: post #5
jerrygenser wrote: post #4

Earlier quoted context omitted.

Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode

It's written in Typescript, which is a super weird choice.

Wasn’t pyright made specifically for VSCode? That would explain TS.

Re: Pyrefly: Python type checker and language server in Rust

#73

Post by flanked-evergl »

ocamoss wrote: post #65
flanked-evergl wrote: post #37

Sadly, the question with both this and ty is: Does it support pydantic? If not, then it's not really helpful for many people, and right now AFAIK neither supports pydantic. Pydantic is probably the problem here, but it is what it is.

Pyrefly actually does have (experimental) support for Pydantic! https://pyrefly.org/en/docs/pydantic/

Nice, did not know.

Re: Pyrefly: Python type checker and language server in Rust

#74

Post by wiseowise »

jon-wood wrote: post #34
jerrygenser wrote: post #4

Earlier quoted context omitted.

Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode

I'm sorry, I can't take seriously any piece of software which decided to prefix the previous version's name with "based". I'm aware this is a me problem.

Definitely this. I commend author of BPyright, but clown (?) avatar, unknown identity of maintainer, and name of the fork rub me off wrong way.

Re: Pyrefly: Python type checker and language server in Rust

#75

Post by wiseowise »

arccy wrote: post #52
vovavili wrote: post #25

Earlier quoted context omitted.

uv works so well for the vast majority of scenarios that I don't really see a demand for further innovation in the Python package manager domain.

yeah we all heard that story every 3 months with all the previous package managers. until there's adoption by an overwhelming majority of projects, it isn't really settled yet.

I’ve literally never heard that much buzz and excitement about Python tool before. And I’ve seen them all.

All of them had some big issue that prevented it from getting mainstream. Either it was slow, or didn’t work with existing workflow, or had complex configuration, or something that prevented gradual adoption.

uv is universally praised as the second coming Christ in Python world (and for a good reason). So no, I doubt there will be something else. Not only you need to be better than uv, you also need to have community momentum.

Re: Pyrefly: Python type checker and language server in Rust

#76

Post by eqvinox »

notatallshaw wrote: post #71
eqvinox wrote: post #69

Earlier quoted context omitted.

> You can take a look yourself if you think some of them are wrong: https://github.com/python/typeshed/tree/main/stdlib/asyncio Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't: ERROR Argument `Future[list[BaseException | Any]]` is not assignable to parameter `future` with type `Awaitable[tuple[Any]]` in function `asyncio.events.AbstractEventLoo…

> Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't: > …where is it even puling "tuple[Any]" from… Perhaps it's a bug in pyrefly, perhaps mypy or pyrefly is able to infer something about the types that the other isn't. I would strongly suggest checking their issues page, and if not seeing a report already report it yourself. While there is an ong…

> it does not actually cover what rules you can check or infer from type hints

Indeed this is the cause of maybe 30% of the warnings I'm seeing… items being added to lists or dicts in some place (or something else making it infer a container type), and pyrefly then refusing other types getting added elsewhere. The most "egregious" one I saw was:

  def something(x: list[str]) -> str:
      foo = []
      for i in x:
          foo.append(i)
      return "".join(foo)
Where it complains:

  ERROR Argument `str` is not assignable to parameter `object` with type `LiteralString` in function `list.append` [bad-argument-type]
   --> test.py:4:20
  4 |         foo.append(i)
Edit: now that I have posted it, this might actually be a bug in the .join type annotation… or something

Edit: nah, it's the loop (and the LiteralString variant of .join is just the first overload listed in the type hints)… https://github.com/facebook/pyrefly/issues/1107 - this is kinda important, I don't think I can use it before this is improved :/

Re: Pyrefly: Python type checker and language server in Rust

#77

Post by notatallshaw »

whalesalad wrote: post #15

Python is starting to feel a bit like JavaScript circa 2014. Remember grunt, gulp, webpack, coffeescript, babel? Now we've got pyright, mypy, pyrefly, black, ruff, ty, flake8, poetry, uv... I used to find this kind of tooling explosion exhausting (and back then with JS it truly was), but generally speaking it's a good sign that the community is hungry to push things forward. Choice is good, as long as we keep the Uni…

A lot of the tools you list here are composable, mypy checks type hints, black formats code, because of the purpose and design ethos of those two tools they would never think to merge.

So which is it that you want, to just reach for one tool or have tools that have specific design goals and then have to reach for many tools in a full workflow?

FWIW Astral's long term goal appears to be to just reach for one tool, hence why you can now do "uv format".

Re: Pyrefly: Python type checker and language server in Rust

#78

Post by JimDabell »

maleldil wrote: post #70
JimDabell wrote: post #12

Earlier quoted context omitted.

It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL): https://github.com/microsoft/pyright/issues/1739 https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-LBYL

Sometimes dynamic Python idioms are incompatible with typed Python. I personally think that's fine, since I consider static typing a significant improvement overall.

This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way:

> I think EAFP is a very unfortunate and ill-advised practice.

They want you to not write the idiomatic Python:

    try:
        foo = bar["baz"]["qux"]
        ...
    except KeyError:
        ...
…and instead write the non-idiomatic version:

    if "baz" in bar and "qux" in bar["baz"]:
        foo = bar["baz"]["qux"]
        ...
    else:
        ...
If this were a linter then I would accept that it is going to be opinionated. But this is not a linter, it’s a type checker. Their opinions about EAFP are irrelevant. That’s idiomatic Python.

Re: Pyrefly: Python type checker and language server in Rust

#79

Post by seabrookmx »

giancarlostoro wrote: post #29
pawelkobojek wrote: post #11

I love the speed advantage of pyrefly over (based)pyright but so far it doesn't seem to highlight as much as pyright does, for example it doesn't catch unreachable code like this: def fn(x: str): if x is None: x = "123" # pyright flags that as unreachable code, pyrefly does not Autocomplete for modules also doesn't work for me yet: import os os. # I'll get `ABC, `Any`, `AnyStr`, `AnyStr_co`, `BinaryIO`, ... Looking f…

It's funny because in other typed languages a string can be null because of string being a reference type as opposed to a value type. I think Python type hints make more sense than C# does in this respect, which gives me a chuckle (two of my favorite languages and the untyped one makes more sense with types). That said, not sure if you already have but I would add a github issue / ticket reporting your issue to raise…

If you use the nullable types compiler option in C# (which defaults to enabled for new projects) then you need to declare you string as string? for it to be nullable :)

Re: Pyrefly: Python type checker and language server in Rust

#80

Post by atoav »

phplovesong wrote: post #67
screye wrote: post #66

Earlier quoted context omitted.

If ruff & uv have proved anything, it's that a tool that's effortless, a net-positive and fast will get adopted. New typecheckers don't need to be perfect. They need to be good enough, easy to integrate and have low false positives. Sure, they will improve with time, but if feels like a pain then no one will pick it up. Python users are famously averse to tools that slow down their dev cycles, even if it means better…

If typechecking is tongue on cheek, why even bother?

If car crashes still kill people, why wear safety belts?
Post reply on HN