241–247 of 247 posts
Every new single piece of software calls itself “extremely fast”, “blazingly fast”, it gets tiring.
ruff is not new. It's also truly really fast. On an as-yet un-ruff'ed 32k SLOC python package it returns in 158ms finding 2k errors. Having it fix errors is also very fast. What's really tiring is reading such facile "critiques", especially when they are not even applicable.
Earlier quoted context omitted.
I don't think people expect import sorting to fix bugs. It's just good (and free!) practice. Anyway I have definitely had linters like Ruff catch bugs. Probably the most common is the mutable default argument gotcha.
I'm not saying that it's not catching bugs. Sometimes it does. But most of the rules are nonsense and the number of rules that makes no sense is growing. Also, mutable default argument is not a bug. It is a bug only if mutable default argument is mutated inside the body of a function/method. Which is almost never the case.
It's quite common in my experience.
And sure it's not always a bug, otherwise Python itself would flag it. The point of linters is to improve code quality to avoid things that are error-prone. This is one of the most error-prone things in Python in my experience.
First would probably be implicit bool coersion (e.g. `if a_string:`) but that can only be caught by a static type checker.
I really wish Ruff would introduce something similar to Nix’s stateVersion, which is used to determine the set of defaults that will be applied. Updating Ruff at a scale beyond a single repo is a bit of a crapshoot currently, with every version introducing a bunch of new default rules which you then have to deal with immediately (either by turning them off or fixing them). I’m aware we could have an allowlist in plac…
Two approaches:
You can pin the version of `ruff` in `pyproject.toml`.
You, to let ruff command version advance but pin the settings to a prior version:
uvx ruff@0.15.22 check --isolated --show-settings | flat2toml > pinned.toml
extend = "pinned.toml"Earlier quoted context omitted.
I don't think it is because spaces vs tabs impacts semantics.
Since this is a long-standing, real-world problem that linters solved, how could it not be relevant to a discussion about the usefulness of linters? And the choice of whether to use tabs or spaces does not affect semantics. It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.
> It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.
This isn't true. It changes how the code can be interpreted by tooling, and it changes how Python interprets the code because it's whitespace sensitive. It's also invisible. It's such an extreme example, I don't think this is reasonable to bring into the conversation for style discussions.
Earlier quoted context omitted.
I also do not like if project stays on 0 version to break compatibility with every minor version. This is the problem with many rust tools and libraries. I think it is unfair to do that years after first release and with healthy community. But it is a tradeoff and not using ruff is in my opinion worse. To your other issues, just do not upgrade. There is no need to upgrade everything a few days after release. I always…
I find it kinda amusing that we seem to have an endless and useless discussion on "what version of ruff to use" now when you kinda implied that you have some sort of a solution to these endless, useless discussions -- in a form of "just use ruff." > upgrade whenever it is convenient In my codebase, and with my environment, the best answer is never . We'll have to pick a second-best answer though.
Earlier quoted context omitted.
You can still talk to them about more important problems than placement of collons and closing bracket.
Actually the aesthetic preferences of people I regularly work with are important to me.
Earlier quoted context omitted.
I find it kinda amusing that we seem to have an endless and useless discussion on "what version of ruff to use" now when you kinda implied that you have some sort of a solution to these endless, useless discussions -- in a form of "just use ruff." > upgrade whenever it is convenient In my codebase, and with my environment, the best answer is never . We'll have to pick a second-best answer though.
Look at ruff blog, they provide config which disables newly added rules. So you can use that and everything will be the same. I have tried ruff today on multiple projects at work and nothing changed because we already use more rules than default. There was zero discussion about that everyone is ok with using linters, formatters and similar tools like deptry or uv-sort.