5 ms·

Speed is a non existent problem for linters. Pyflake is quick enough. I spend more time thinking than writing code. I just write in one file at a time, which ca

by neves 4y ago

Speed is a non existent problem for linters. Pyflake is quick enough. I spend more time thinking than writing code. I just write in one file at a time, which can be linted in sub-second time. How does it compare with Pyflake8 in error messages? Does it find more errors? Does it have less false positives? Does it integrate well with other developers tools? Does it have sane defaults? These are the really important questions that aren't answered in the site.

kstrauser 4y ago
I disagree about the speed. I don't have a problem with pyflake, but running `time ruff -s .` in a project with 1,236 Python files took 78ms. At that speed, it could re-check the file I'm working on in an editor after every keystroke with no noticeable latency. It's not just a little bit faster. It's freakishly, ridiculously, gone-plaid faster. Edit: for comparison, flake8 took 8.19s and found approximately the same number of issues. pyflakes took 4.49s and found fewer.
- mixmastamyk 4y ago
  Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.
  - kstrauser 4y ago
    That’s not true unless you have a dependency map between all modules. (Note: that’s what I did in pytest-fastest to only retest modules that had changed, or that imported modules that had changed.) Otherwise, if you rename a function, you wouldn’t know what all broke.
    - mixmastamyk 4y ago
      You don’t need to check everything, every time. (Another case of yours is when you want all types checked.) Good time for a full check is when new feature is complete. Run all linters, typers, and full test suite, until clear. Then commit and push.
emptysea 4y ago
Speed is a problem for linters. If I spend 200ms of CI time instead of say 5minutes that’s a real difference in toil and CI spend Ruff has an LSP too so it integrates well with editors unlike flake8 and similar which only work on save — and are really slow
- neves 4y ago
  No linter takes 5 minutes to analyze a bunch of modified files for your next commit.
plorkyeran 4y ago
There's three relevant speeds for linters: 1. Fast enough to be live updating as you type in an IDE. 2. Slow enough that running a linter has to be a separate action you take, but fast enough that you don't go do something else while it's running. 3. So slow that it's an asynchronous task that you launch and then come back to later. Ruff is in the first category, while most other python linters are in the second. This level of performance enables a qualitative difference in how you interact with the tool. If you are invoking it as a separate task, then going from 500ms to 50ms is indeed not very interesting, though.
neuronexmachina 4y ago
> How does it compare with Pyflake8 in error messages? https://github.com/charliermarsh/ruff#rules https://github.com/charliermarsh/ruff#rules > Ruff supports over 500 lint rules, many of which are inspired by popular tools like Flake8, isort, pyupgrade, and others. ... By default, Ruff enables Flake8's E and F rules. Ruff supports all rules from the F category, and a subset of the E category, omitting those stylistic rules made obsolete by the use of an autoformatter, like Black. You can see the current list of supported rules here: https://beta.ruff.rs/docs/rules/ https://beta.ruff.rs/docs/rules/ There's also a checklist on this PR which tracks progress on implementing pylint compatibility: https://github.com/charliermarsh/ruff/issues/970 https://github.com/charliermarsh/ruff/issues/970

by neves 4y ago

kstrauser 4y ago

I disagree about the speed. I don't have a problem with pyflake, but running `time ruff -s .` in a project with 1,236 Python files took 78ms. At that speed, it could re-check the file I'm working on in an editor after every keystroke with no noticeable latency. It's not just a little bit faster. It's freakishly, ridiculously, gone-plaid faster. Edit: for comparison, flake8 took 8.19s and found approximately the same number of issues. pyflakes took 4.49s and found fewer.

mixmastamyk 4y ago
Don't need to lint the whole repo, just the files you're working on currently. Git can tell you what has changed.
- kstrauser 4y ago
  That’s not true unless you have a dependency map between all modules. (Note: that’s what I did in pytest-fastest to only retest modules that had changed, or that imported modules that had changed.) Otherwise, if you rename a function, you wouldn’t know what all broke.
  - mixmastamyk 4y ago
    You don’t need to check everything, every time. (Another case of yours is when you want all types checked.) Good time for a full check is when new feature is complete. Run all linters, typers, and full test suite, until clear. Then commit and push.

emptysea 4y ago

Speed is a problem for linters. If I spend 200ms of CI time instead of say 5minutes that’s a real difference in toil and CI spend Ruff has an LSP too so it integrates well with editors unlike flake8 and similar which only work on save — and are really slow

neves 4y ago
No linter takes 5 minutes to analyze a bunch of modified files for your next commit.

plorkyeran 4y ago

There's three relevant speeds for linters: 1. Fast enough to be live updating as you type in an IDE. 2. Slow enough that running a linter has to be a separate action you take, but fast enough that you don't go do something else while it's running. 3. So slow that it's an asynchronous task that you launch and then come back to later. Ruff is in the first category, while most other python linters are in the second. This level of performance enables a qualitative difference in how you interact with the tool. If you are invoking it as a separate task, then going from 500ms to 50ms is indeed not very interesting, though.

neuronexmachina 4y ago

> How does it compare with Pyflake8 in error messages? https://github.com/charliermarsh/ruff#rules https://github.com/charliermarsh/ruff#rules > Ruff supports over 500 lint rules, many of which are inspired by popular tools like Flake8, isort, pyupgrade, and others. ... By default, Ruff enables Flake8's E and F rules. Ruff supports all rules from the F category, and a subset of the E category, omitting those stylistic rules made obsolete by the use of an autoformatter, like Black. You can see the current list of supported rules here: https://beta.ruff.rs/docs/rules/ https://beta.ruff.rs/docs/rules/ There's also a checklist on this PR which tracks progress on implementing pylint compatibility: https://github.com/charliermarsh/ruff/issues/970 https://github.com/charliermarsh/ruff/issues/970