141–150 of 296 posts
Earlier quoted context omitted.
Found 275 diagnostics 0.56s user 0.14s system 302% cpu 0.231 total Damn that's fast. And zero issues in this project with pyright so curious that these are...
There's a good chance many of the errors we emit are incorrect, at this stage. Lots to do still!
Carl, you did not tell me that the errors we emit need to be correct!!
I think I need to go revisit some of my PRs...
Earlier quoted context omitted.
how does it compare against mypy? is it much faster?
How does it compare against Pyright . Pyright is the gold standard of Python type checking currently. Mypy is slower and buggier.
Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives
Pyright: 13.6 seconds, 10 errors, all of which are actually real errors
There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet.
Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen.
Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.
Just compared the time to check on a fairly large project: - mypy (warm cache) 18s - ty: 0.5s (and found 3500 errors) They've done it again.
Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright
Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives
Pyright: 13.6 seconds, 10 errors, all of which are actually real errors
There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet.
Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen.
Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.
Recently I started a python project and I wanted to do it the "proper" way. mypy + pylint. But even on this small 15-20kloc program these tools are way to slow to do anything in realtime. It takes double digit seconds to have feedback. Way to long for an LSP. I'm honestly appalled the state of affairs is this bad. What the hell do people do with moderately or even large sized code bases?
How does Astral plan on making money?
Earlier quoted context omitted.
There's a good chance many of the errors we emit are incorrect, at this stage. Lots to do still!
Wait wait wait Carl, you did not tell me that the errors we emit need to be correct !! I think I need to go revisit some of my PRs...
I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.
prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's astral have now replaced the awful pip with the fantastic uv various awful linters with with the fantastic ruff and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one! I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!
Even after all the praise, I'd say they're underrated. Modular.ai raised $100 million to solve tangentially similar problems with python. Astral has already had a much larger impact, while providing better integration with less than 10% of that money.
you could even say that astral and modular focus on two extreme ends of the developer experience spectrum - just making python tooling faster, vs making python-ish code faster.