21 ms·
Even the Pylint codebase uses Ruff
- asah 4y agoI wonder if ChatGPT could be used to port more rules from pylint to ruff ?
- the_sleaze9 4y agoThis honestly depends on whether you are familiar enough with the Ruff codebase and Rust syntax, no different than just "doing it by hand". At this point (IMHO) ChatGPT does not make a meaningful difference in the production of software, aside from individual workflow preferences. The reason being ChatGPT will produce a lot of computer code which is very likely to be subtly incorrect in difficult to spot places.
- BiteCode_dev 4y agoIs ruff a good replacement for pylint yet ? It replaces flake8 well but since I use black and pylint, I don't need flake8. However, pylint does a lot so if it does replace it, even without plugins, that would be amazing.
- VeejayRampay 4y agoruff is exceptionally fast and capable, but doesn't handle all constructs, match/case are not handled correctly yet for example
- deckiedan 4y agoMatch is now supported (as of last week) I believe
- VeejayRampay 4y agowow nice
- BiteCode_dev 4y agoPylint value, unlike flake8, is not in checking formatting but rather naming conventions, code complexity, and basic code sanity. Do you use pylint ? If yes what are the important pylint checks you missed in ruff?
- andrewshadura 4y agoDoes Ruff support configuration in setup.cfg?
- openpaycard 4y ago[flagged]
- peefy 4y agoI'm glad to see the organic combination of Python and Rust. My personal interesting experience is to rewrite a Python project using Rust [1], which has increased the speed by 40 times. Then the original Python project and the rewritten Rust code are organically combined through PyO3, which is very good. We have not only achieved performance, but also achieved ease of use and scalability. Just like PyLint and Ruff. [1] We Rewrote Our Project With Rust… and It’s Almost 40X Faster. https://medium.com/better-programming/40x-faster-we-rewrote-our-project-with-rust-120b006c6abe https://medium.com/better-programming/40x-faster-we-rewrote-...
- theusus 4y agoI have the best experience with Pylance. And I am talking about editor extensions.
- mkl 4y agoRuff is another Python linter, written in Rust. https://github.com/charliermarsh/ruff https://github.com/charliermarsh/ruff
- earthboundkid 4y agoWho lints the linters?
- Ar-Curunir 4y agoas per this thread, other linters =P
- speed_spread 4y agoIt's linters all the way down!
- astrea 4y agoThe dryer
- AgentOrange1234 4y agoAs a member of the uninitiated, it would be great if these kind of posts could include some context on what Ruff is and why this is significant?
- rodrigobellusci 4y agoIt's a python linter, from what I've seen.
- qbasic_forever 4y agoImplemented in rust, not python, so it's extremely fast. It's orders of magnitude faster than pylint itself.
- furyofantares 4y agoHow many orders of magnitude?
- qbasic_forever 4y agoThere's a very clear graph the first thing on ruff's GitHub page, easy to find and research yourself: https://github.com/charliermarsh/ruff https://github.com/charliermarsh/ruff Can't miss it if you take time to check out the project.
- furyofantares 4y agoSo 2, maybe 3
- deleted 4y ago[deleted]
- p5a0u9l 4y agoYour comment seems skeptical. Practically, It’s a night and day difference if you’ve integrated a linter with your editor. Plus, ruff is able to fix as well as lint.
- brigandish 4y agoI clicked through, did a search for Ruff, then looked up the Github project. Okay, but… so what? Is this another case of "I rebuilt X in Rust and hit the front page of HN"? It seems so.
- DanielVZ 4y agoIt’s a big deal because normally linters have been written in pure python and they are prohibitively slow for large code bases. This tool provides an important speedup that will save my team hour’s of waiting for CI.
- fbdab103 4y agoI am curious how big your codebase is that it saves hours. I never found the existing Python based tooling to be slow enough that I felt the need to consider alternatives. Though, I will gladly take the speedup.
- lost_tourist 4y agoAny program that took longer than several minutes to "lint" for me seemed to blow up anyway, usually by running out of memory or hitting some infinite recursion.
- scbrg 4y agohttps://xkcd.com/1205/ https://xkcd.com/1205/ is relevant here. Our codebase is somewhere between 200k and 300k LOC. Running the flake8 suite takes minutes. We haven't integrated ruff, but during a test run it ran in less than a second, IIRC. So, with, say 20-30 commits per day, that's about an hour, every day. Sure, it's not like we're usually sitting there twiddling our thumbs during builds, but sometimes we actually do have to wait for a build to get ready. Just the waiting time during those rare occasions add up. [edit]: flake8, remarkably, dropped roughly an order of magnitude in performance between version 2 and 3. So that didn't help.
- pydry 4y ago
- zzzeek 4y agojust tried it and this is immensely fast. too bad it doesn't appear to support flake8 plugins and only has a small subset hardcoded into it. if it could support arbitrary flake8 plugins I would move SQLAlchemy to this tool immediately. the main reason people want to move off flake8 is not so much a speed issue but that its author refuses to allow it to use pyproject.toml files for configuration, meaning every project's configuration has to remain half-broken using obsolete setup.cfg files. A very silly situation.
- emptysea 4y agoyeah that pyproject.toml issue is really annoying with flake8, made me glad to switch to ruff even though it doesn't have all the same lints available
- charliermarsh 4y agoYeah we don't support arbitrary Flake8 plugins. We do plan to support plugins eventually but the exact architecture and API are TBD. If there are plugins that would be particularly impactful for you, I'd be happy to take a look at adding them. (We support some of the plugins you use in SQLAlchemy, like flake8-docstrings and flake8-builtins, but not flake8-rst-docstrings which I'm guessing is a blocker.)
- zzzeek 4y agothanks for the reply! we use a bunch of goofy ones that nobody else does. one of them is like a 3 line plugin that has only a handful of stars on github. flake8-import-order flake8-builtins flake8-future-annotations flake8-docstrings flake8-rst-docstrings flake8-import-single
- charliermarsh 4y agoOh heh yeah I saw flake8-import-single :) That might be equivalent to using Ruff's isort implementation with `force_single_line` but maybe that comes with other implications that you don't want for SQLAlchemy.
- muglug 4y agoContext: Ruff is a Rust-based linter for Python. It’s much faster than Python-based linters for Python because Rust is much faster than Python. There are a couple of drawbacks to Ruff that mean it may not be right for everyone: since it’s a compiled tool, it’s harder to add custom rules — you need to fork the project to add your own, and also you need to know some Rust. When checking the Pylint codebase it makes sense to use Ruff as well as Pylint — it’s a good sanity check that Pylint’s own tooling is not letting issues through that another tool is catching.
- bjourne 4y agoHow many thousands of lines of code do you need to lint before Rust's performance advantages actually matter? After all, performance optimizing a tool where N is too small to matter is the root of all evil. Keep in mind that you don't have to lint an already linted file if you cache its hash.
- vitorsr 4y agoTo add to your comment: I also think that these rewrites are throwing the baby out with the bathwater. Especially in projects related to code quality and analysis, things like widespread adoption and issues going back almost a decade are much more important than raw performance. For every aspect of functionality, there is a heavy baggage of quirks, bugs, edge cases etc. I am not convinced that a rewrite of a tool that is still in development and still limited to a subset of functionality is able to capture nearly a decade of community work.
- nindalf 4y agoThe author of Ruff mentioned that many people told him exactly what you're saying. He went ahead and built it anyway. I'm puzzled though. Those naysayers were naysaying about an attempt at rewriting. You appear to be naysaying a successfully built project. It's true that the folks who find it most helpful are the ones with large Python projects. But these are sometimes very important, widely used projects. See the testimonials from users (https://beta.ruff.rs/docs/#testimonials https://beta.ruff.rs/docs/#testimonials) > widespread adoption This makes little sense in the context of a linter. As long as my linter implements all the popular rules and my code is kept tidy, what's the issue? What does it matter if there's widespread adoption or not? > still limited to a subset of functionality You have a link to some functionality you're missing and necessary for your workflow? Or is this more of a theoretical concern? Sorry if this comes across as rude.
- SuperSandro2000 4y agoSee https://github.com/charliermarsh/ruff/issues/970 https://github.com/charliermarsh/ruff/issues/970 for a comparison between pylint and ruff
- gempir 4y agoThere are a lot unchecked boxes in that list. But I'm looking forward to the progress of this project.
- Rauchg 4y agoVery excited to see the Rust-ification of Python tooling, similar to what we’re seeing in the JavaScript[1] tooling ecosystem. [1] https://leerob.io/blog/rust https://leerob.io/blog/rust
- wiz21c 4y agowaiting for rusthon.
- KptMarchewa 4y agoIt exists: https://github.com/RustPython/RustPython https://github.com/RustPython/RustPython
- deleted 4y ago[deleted]
- izik 4y agoIt is already happening and with the availability of the tools like PyO3 [1] (it allows Python developers to write performance-critical code in Rust and then expose it as a Python module) the Rustication of the Python will be progressing while some controversies will appear [2]. Adding new language adds complexity to the python code base but it is always good to have at least choice and decide case-by-case if use Rust in Python app or not. [1] https://github.com/PyO3/pyo3 https://github.com/PyO3/pyo3 [2] https://safjan.com/rustification-of-python/#drawbacks-and-controversies-around-the-rustification-of-python https://safjan.com/rustification-of-python/#drawbacks-and-co...
- Rauchg 4y agoNice references, thanks for sharing!
- deleted 4y ago[deleted]
- galoisscobi 4y agoI was excited to start using Ruff however it has quite a few ruff edges for me to use professionally. Back to pylint for now, but looking forward to adopting it once it's ready. The difference in speed was night and day. Another feature I hope to see in Ruff is to "score" the code. With pylint, I can have a CI rule to make the lint check pass if it scores 8/10 or above, or even a lower score so that co-workers who resent using linters can start using them.
- rtpg 4y agoI had started writing a 1-for-1 Pylint port in Rust (almost nowhere right now), but Ruff has gotten there way faster. Props! Pylint is rough to make faster, party from the existing structure, but honestly at one point you are just paying a huge cost for traversing wide ASTs and doing all this work, and then paying extra for the Python object model. In my profiling of Pylint, I've found some fixes, and I am curious about what something like slots or mypyc could do to it... but I'm also very partial to just having a system language implementation. People talk about ease of contributing as a big advantage for these kinds of tools to be written in the language they are working on. Personally I've found that people who like messing with tools like the idea of learning languages to contribute. My one kind of reservation about Ruff is that the code base is designed as "run each checker as its own function". My suspicion is that this leads to a performance ceilings as each checker is traversing the AST looking for its flavor of thing. Visitor patterns (theoretically!) allow for us to run checkers in parallel nicely. Granted the Ruff pattern allows for parallel work as well (and you can share all of the AST data between threads anyways), so maybe its "right". It definitely looks easier to maintain!
- drothlis 4y agoCould you implement (some of) astroid's inference using stack graphs? [1],[2] That would allow a lot of caching optimisations, as you can "index" each file in isolation. [1]: https://github.blog/2021-12-09-introducing-stack-graphs/ https://github.blog/2021-12-09-introducing-stack-graphs/ [2]: https://github.com/github/stack-graphs https://github.com/github/stack-graphs