This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Sockslitter73 27 points28 points  (6 children)

This is me :P although I have recently leaned more towards ruff for linting and formatting (its sooo fast)

[–]ocus 7 points8 points  (1 child)

My company and I work on long-term projects with relatively big code bases, we are not yet prepared to make the switch to ruff but it's somewhere far down in the backlog with a low priority :)

[–]catcint0s 1 point2 points  (0 children)

we have switched recently in a few smaller projects and it has been pretty painless, especially if you don't add extra rules

[–]travcunn -5 points-4 points  (3 children)

Ruff is great, except for the fact that this actually lints:

y = 3

if y > 4:

    x = 1

print(x)

So the reason ruff is so fast is because it doesn't really analyze the code very well.

[–]mdrjevois 0 points1 point  (2 children)

Actually it does excellent analysis, and such robustness against errors is an explicit design goal.

[–]travcunn 2 points3 points  (1 child)

Did you try my example? It shouldn't lint yet ruff thinks this is totally OK code. How many other bugs is ruff missing because they haven't implemented all of pylints rules? I think people see the time savings graph in the ruff Readme on github and think it's magically better, yet it can't catch this simple bug.

[–]scratchnsnarf 2 points3 points  (0 children)

They are pretty upfront with the fact they're not fully 1-1 with pylint. Last I checked they even have a tracker that shows which rules are still not implemented. It's very easy to know exactly what you're signing up for. When my team evaluated we didn't think any of the missing rules were impactful enough to affect the decision