Pyright was itself a big improvement over Mypy. Just look at this for starters: https://htmlpreview.github.io/?https://github.com/python/typ...

If Astral can leapfrog Pyright too, great. But I think it will be significantly harder than leapfrogging Flake8 and Black was.

What benefits does uv have over poetry?

In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.

uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks

I really haven't been able to understand why "managing the Python version" is such a big value add for so many people. I just have each version built from source and make venvs from them as needed.

Because most people don't build their toolchain from source anymore. When I am trying to help a junior programmer get up and going, it's a lot easier to say "OK, just do `brew install uv` then `uv sync` in the project folder and you are all set" than to try to walk them through building from source.

Not to mention being able to have reproducible builds for deployments, CI/CD, etc. The fact that the Python version is picked up from the project's package configuration is nice because then you don't have to remember to update the source build to match when you update pyproject.toml for a new Python release.

I happen to have built the interpreters (not an entire toolchain) from source. But I could equally well have obtained them from a PPA or whatever else. On Windows I could have used the official installers. The point is that once I have base environments, creating venvs is trivial.

(And really, the experience of building Python from source on Mint was about as smooth as I could have ever hoped for.)

>when you update pyproject.toml for a new Python release.

? I don't upper-cap the Python version (or anything else without a well-defined reason - https://iscinumpy.dev/post/bound-version-constraints/ ) so I wouldn't be updating anyway. If I want to test under a new Python version then I need to write that out explicitly somewhere regardless; might as well do it on the command line.

Speed, compatibility, ergonomics, standards compliance.

also a whole bunch of new features (--script mode), speed of development, a stacked team.

Works with pytorch.

Pylance is nicer than pyright, but unfortunately I don't think you can use it outside of vs code

pylance is pyright under the hood, isn't it? it's the main reason I use pyright over mypy: I work in VSCode and I want compatible type checking

It's not clear to me that they are building an alternate type checker per se

Seems like `ruff server` is an LSP?

Yes but only for linting (the flake8 rules etc). The end goal is to have proper type checking and, I think, proper LSP refactoring capabilities.

they are working on it! the internal name is currently red-knot (you can see it in their GH History and in the discord). First thing is a type checker, I think, then the renaming capabilities and such.

True, what I would really need is a uv based pyinstaller alternative