Pyrefly: A new type checker and IDE experience for Python • Hacker News Board

Re: Pyrefly: A new type checker and IDE experience for Python

#101

Post by WD-42 » Sat, May 17, 2025, 8:40 PM UTC

mnahkies wrote: post #48

munro wrote: post #21

Earlier quoted context omitted.

That's sort of how I felt about things before, but the reality I believe is we wouldn't have uv if they 'just contributed to poetry'.

I tend to agree. I don't know the differences between the two well enough to know if it was the case here, but in my experience sometimes you need to innovate on a fork, or from scratch in order to create the space/freedom to do so. Once a project is popular, it's harder to justify and be confident about major changes (aka https://m.xkcd.com/1172/ )

It seems like the share a lot of the same goals but my impression is Poetry is much slower to pick up on standards. It’s normal to use uv with a project now that doesn’t have any [tool.uv] section in pyproject.toml at all but every poetry project I’ve seen is littered with [poetry] sections, even dependencies. Makes me not want to use it

Re: Pyrefly: A new type checker and IDE experience for Python

#102

Post by nine_k » Sat, May 17, 2025, 8:55 PM UTC

90s_dev wrote: post #84

owebmaster wrote: post #76

Earlier quoted context omitted.

JSX does not support any of these, it was coded by others. tagged template literals can have all of these, some already exist¹ and doesn't need a build step. 1. https://marketplace.visualstudio.com/items?itemName=bierner....

The only inherent feature of JSX is compile time "parsing" whereas tagged literals inherently require runtime string parsing. But yeah other than that you're right. I'm just talking about first-class VS Code support. Which to me means a lot.

Of course tagged string literals can be compiled down to a form where no string parsing occurs. This is a really old technique; I implemented it, like many others, in PHP in late 1990s.

Vut inside an IDE or an LSP, tagged literal strings need quite a bit more special support than JSX, AFAICT.

Re: Pyrefly: A new type checker and IDE experience for Python

#103

Post by nine_k » Sat, May 17, 2025, 9:01 PM UTC

doug_durham wrote: post #49

Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.

An LSP is performance-critical code. It directly affects responsiveness of your IDE, or even the viable scope of a project that the LSP can handle.

Rust is both CPU- and memory-efficient, quite unlike Python. (It could have been OCaml / Reason, or Haskell, they are both reasonably fast and efficient, and very convenient to write stuff like typecheckers in. But the circle of possible contributors would be much narrower.)

Re: Pyrefly: A new type checker and IDE experience for Python

#104

Post by nine_k » Sat, May 17, 2025, 9:04 PM UTC

melodyogonna wrote: post #64

The Rust code written here is so easy to follow but all these new Python tooling being written in Rust worries me, it adds yes another vector to the N-language problem. I hope Mojo can offer something here

For the Python ecosystem, it's natural to use Python where Python can cope, and a high-performance language where it cannot. There are two such languages in wide use around Python: Rust, and, inevitably, C. So N = 3.

(C, to my mind, should be eventually phased out from application programming altogether, so N would be 2, but it's a loooooong process; Python may become a legacy language before it converges.)

Re: Pyrefly: A new type checker and IDE experience for Python

#105

Post by lynndotpy » Sat, May 17, 2025, 9:10 PM UTC

rafram wrote: post #96

lynndotpy wrote: post #56

Earlier quoted context omitted.

Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.

Rust has very arcane syntax and a lot of rules that developers coming from interpreted / garbage-collected languages (like the ones using these tools) would have a hard time grasping. It’s easy for people who are already familiar with it, but isn’t that always the case?

I'm saying the opposite, actually. I found it easier to contribute to Rust projects (with zero hours Rust experience, and much Python/Java/C/C++/Ada) because Rust projects are significantly easier to build. (Just a `cargo build` in the default case.)

Re: Pyrefly: A new type checker and IDE experience for Python

#106

Post by mdaniel » Sat, May 17, 2025, 9:36 PM UTC

mixmastamyk wrote: post #100

mdaniel wrote: post #99

Earlier quoted context omitted.

This response highlights both parts what I was saying: it's not just strings, and "I'm sure there's some extra things that the standard library wants you to duct tape together, good luck"

It is exactly two strings that are required. The docs are there for flags etc, use them. Types were not entered directly into stdlib source for historical reasons. If you would enjoy further support, install stubs from typeshed.

> It is exactly two strings that are required

It is exactly as I said, it's not just strings

    $ python3.12 -c '
    import re
    pat = re.compile("who knew")
    ma = re.match(pat, "who knew types matter")
    print(ma)
    '

> The docs are there for flags etc, use them.

I guess it's good we're all using LLMs nowadays, since in general computers no read so good, that's why we write in specialized languages for their benefit. That would include this fancy new thing I've heard about where one writes down what the input and output domains are for functions

> Types were not entered directly into stdlib source for historical reasons.

Historical reasons defeats the purpose of having git tags, to say nothing of them having several concurrent branches named after the various release trains. I mean, historically print was a keyword, but you sure don't see them from __future__ import print_statement all over the 3.12 tree now do you? It's because they DGAF preferring there to be seemingly unlimited aftermarket tooling to try and drag python3000 into the 21st century

> If you would enjoy further support, install stubs from typeshed.

While trying to dig up whatever a sane person would use to "install stubs" -- because it for damn sure isn't $(pip install typeshed) -- I learned that you were even more incorrect - it accepts bytes, too https://github.com/python/typeshed/blob/9430260770b627c04313...

Anyway, they also go out of their way to say "don't install typeshed" and I guess that's why they don't have any git tags because releases are for children

Re: Pyrefly: A new type checker and IDE experience for Python

#107

Post by mixmastamyk » Sat, May 17, 2025, 9:59 PM UTC

mdaniel wrote: post #106

mixmastamyk wrote: post #100

Earlier quoted context omitted.

It is exactly two strings that are required. The docs are there for flags etc, use them. Types were not entered directly into stdlib source for historical reasons. If you would enjoy further support, install stubs from typeshed.

> It is exactly two strings that are required It is exactly as I said, it's not just strings $ python3.12 -c ' import re pat = re.compile("who knew") ma = re.match(pat, "who knew types matter") print(ma) ' > The docs are there for flags etc, use them. I guess it's good we're all using LLMs nowadays, since in general computers no read so good, that's why we write in specialized languages for their benefit. That would…

Right, the first arg can also be a compiled pattern|bytes. Not an issue in the real world however. The problem is when it can't handle what you give it, not when it can handle what you give it and additional things.

Normally you'd use `pattern.match(string)` in that case.

They said specifically more than once that they're not going to change (almost) every line in the repo for any reason, and not only to types but other syntax improvements. Probably to keep git blame intact and avoid introducing new bugs.

Honestly, this reads as an obsession with theoretical concerns.

Re: Pyrefly: A new type checker and IDE experience for Python

#108

Post by maleldil » Sat, May 17, 2025, 10:56 PM UTC

nine_k wrote: post #103

doug_durham wrote: post #49

Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.

An LSP is performance-critical code. It directly affects responsiveness of your IDE, or even the viable scope of a project that the LSP can handle. Rust is both CPU- and memory-efficient, quite unlike Python. (It could have been OCaml / Reason, or Haskell, they are both reasonably fast and efficient, and very convenient to write stuff like typecheckers in. But the circle of possible contributors would be much narrowe…

To be fair, pyright's performance as an LSP is tolerable. The main issue to me is running the type checker as a pre-commit hook or as part of CI. Mypy is awful, though.

Re: Pyrefly: A new type checker and IDE experience for Python

#109

Post by maleldil » Sat, May 17, 2025, 10:58 PM UTC

mixmastamyk wrote: post #93

dist-epoch wrote: post #79

Earlier quoted context omitted.

> I'd prefer to have non-performance critical code for Python written in Python A type checker is performance critical code. You can watch how Pylint, just a linter, written in Python, lints your source code line by line. It's so slow it can take 30 seconds to update the linting after you change some lines.

Many of these make the mistake of running against an entire codebase instead of checking vcs first and only running against changed files.

You still need to type-check files that weren't changed if they were affected by a file that was.

Re: Pyrefly: A new type checker and IDE experience for Python

#110

Post by fluidcruft » Sat, May 17, 2025, 10:59 PM UTC

nine_k wrote: post #104

melodyogonna wrote: post #64

The Rust code written here is so easy to follow but all these new Python tooling being written in Rust worries me, it adds yes another vector to the N-language problem. I hope Mojo can offer something here

For the Python ecosystem, it's natural to use Python where Python can cope, and a high-performance language where it cannot. There are two such languages in wide use around Python: Rust, and, inevitably, C. So N = 3. (C, to my mind, should be eventually phased out from application programming altogether, so N would be 2, but it's a loooooong process; Python may become a legacy language before it converges.)

Yes but the idea is that by slightly upgrading python code to mojo (which is a controlled superset of python), you get complied very high performance code. So for example if it were possible to convert mypy to mojo it could be as fast as rust but pythonic.