This release includes the Beta version of the Ruff formatter — an extremely fast, Black-compatible Python formatter.
Try it today with ruff format.
Changes
Preview features
[pylint] Implement non-...
The question isn’t a matter of creating a unified tool but of figuring out why past attempts (e.g. poetry) haven’t taken off more and if those problems can be avoided.
The only thing holding poetry back is still not supporting the standardized pyproject.toml. That’s the closest thing to cargo that we have. And issues related to various ML libraries
I see typechecking as the next natural extension to this. Won’t be easy, it’s probably the trickiest thing to do well, but it would be the ultimate python tool if it did that. It’s a natural extension point as well, since they have the parsing down.
For me, a big problem with poetry is the author’s insistence on being as strict as cargo on dependency resolution when the Python ecosystem doesn’t have the culture to go with it. You need to be able to override bad transitive dependencies.
The question isn’t a matter of creating a unified tool but of figuring out why past attempts (e.g. poetry) haven’t taken off more and if those problems can be avoided.
The only thing holding poetry back is still not supporting the standardized pyproject.toml. That’s the closest thing to cargo that we have. And issues related to various ML libraries
I see typechecking as the next natural extension to this. Won’t be easy, it’s probably the trickiest thing to do well, but it would be the ultimate python tool if it did that. It’s a natural extension point as well, since they have the parsing down.
There’s pylyzer for a Rust-based type checking LSP alternative to Pyright, but I couldn’t really get it to work with Neovim.
For me, a big problem with poetry is the author’s insistence on being as strict as cargo on dependency resolution when the Python ecosystem doesn’t have the culture to go with it. You need to be able to override bad transitive dependencies.