Live data from Hacker News

Pyrefly: A new type checker and IDE experience for Python

engineering.fb.com

151–160 of 177 posts

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

#151

Earlier quoted context omitted.

Sounds a lot like TypeScript and Flow.

Sure, but in this case they are both implementations of a spec defined by PEPs, so a bit more like gcc vs clang (less tightly bound than those, of course, in design decisions). Neither company is trying to invent a new language here.

The current major type checkers, mypy and pyright, are also based on the same PEPs, but you can still see differences between them. For example, my codebase passes pyright in strict mode, but mypy results in a bunch of type errors. I'd expect pyrefly and ty to be slightly different from each other.

See also:

https://github.com/microsoft/pyright/blob/main/docs/mypy-com...

https://htmlpreview.github.io/?https://github.com/python/typ...

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

#152
post #26

Earlier quoted context omitted.

Pydantic got the re write in rust treatment so de/serialization is crazy fast now.

msgspec must be insanely fast then: https://jcristharif.com/msgspec/benchmarks.html But of course unless parsing and manipulating JSON is your bottleneck, Pydantic is great, too.

It's true. msgspec has incredibly fast msgpack serialization. It's a shame so few people know about it.

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

#153
post #120

Hi folks, I work on the Pyrefly team at Meta. Our FAQ covers a good number of the questions raised here: https://pyrefly.org/en/docs/pyrefly-faq/ . I can also try to answer some of your questions. Thanks for taking a look!

At Slack we have an internal Rust-based Hack typechecker that’s about 20% faster than the OCaml one (we use both) Did you see better speedups over Pyre? Aka did I leave stuff on the table…

Hack is quite a bit more optimized than Pyre was, but Pyrefly is at least 10x faster than Pyre on the IG codebase.

I didn’t know about the Rust-based Hack checker— that’s really cool!

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

#154

I just tried pyrefly on a project that really needed it. It complained about an assignment of a new value to a global int variable within a function, even though the function contained the 'global' statement that should have made that OK, I think. I know that globals and assigning to them here and there are problematic for real good software, but I am surprised that Pyrefly is stricter than python on something that I…

Thanks for trying it out! If you run into any blockers, please let us know by filing a GitHub issue or sending us a message on Discord. Pyrefly is still alpha software, so bugs are expected, but your feedback is extremely valuable as we work to squash them.

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

#155

Earlier quoted context omitted.

Sounds a lot like TypeScript and Flow.

Sure, but in this case they are both implementations of a spec defined by PEPs, so a bit more like gcc vs clang (less tightly bound than those, of course, in design decisions). Neither company is trying to invent a new language here.

the specs are still evolving, and the various type checker implementations are what is driving them forward. in general, capturing the dynamic typing semantics of python in a gradually typed system is not a fully solved problem, and the type checkers are experimenting with various approaches to it.

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

#156

This is very cool but why wouldn’t they just contribute to uv and ruff and ty https://github.com/astral-sh/ty

I just ran ty and it can't resolve any imports whereas pyrefly passes. Why would that be? I hate Python so much.

I love the language, but I do hate the import system too, it makes everything harder

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

#157

To repeat an earlier comment of mine from the launch of uv on hn (tl; dr: these new type checkers never support django): The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wis…

these are two different issues. supporting django involves adding a special-case module that essentially replicates its code generation and then adds that to the type-level view of the code. pyrefly or ty could do that and would still be just as fast. my guess is that once they have the basic python type checker as close to 100% as they can, they will start looking at custom modules for various popular metaprogramming libraries, or add enough of a plugin framework that the community can contribute them.

source: spent several years working on a python type checker

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

#158

I lost all interest when I saw VS Code. I don’t get why people consider this a suitable IDE for python when you can have a real IDE like PyCharm.

fortunately the LSP protocol means you can use pyrefly with whatever ide or editor you like!

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

#159
post #152

Earlier quoted context omitted.

msgspec must be insanely fast then: https://jcristharif.com/msgspec/benchmarks.html But of course unless parsing and manipulating JSON is your bottleneck, Pydantic is great, too.

It's true. msgspec has incredibly fast msgpack serialization. It's a shame so few people know about it.

JSON, too!
Post reply on HN