4 ms·

So much marketing coolaid/bullshit. I'm not that fan of Ruff because to me it doesn't make any sense to add a rust dependency to "python" and it blows my mind

So much marketing coolaid/bullshit. I'm not that fan of Ruff because to me it doesn't make any sense to add a rust dependency to "python" and it blows my mind that people are so keen to accept the ugly formatting inherited from Black just because "it gives consistency to the team, so I don't have to think, and we don't have to discuss code style"... But all of that personal opinion set aside, what triggers my initial statement is that so many persons are so excited to run to use Ruff because... "It is so fast"... when I'm quite sure most of them would never notice any real speed difference with their modest codebase. In almost all the codebases I have seen, proprietary and OSS, pylint or any other linter was quasi-instant. There are probably a few huge codebases that would see a speed benefit of a few seconds to use Ruff, but their owner would probably better have a look at their code to understand how their reached such a monster!

Terretta 2y ago
> quite sure most of them would never notice any real speed difference with their modest codebase On the contrary, within only a year or so of coding by a small team, this ecosystem takes single digit seconds or less, while the traditional tools are taking minutes and more. Particularly in analytics or scientific computing we've seen minutes versus under a second. Having the tools not require additional/parallel Python dependency management is a plus. Note that we watched these tools for a long time, and jumped in when rye converged with uv. It was promising to see fewer ways to do it. // More on that here: https://news.ycombinator.com/item?id=41309072 https://news.ycombinator.com/item?id=41309072
sunshowers 2y ago
Personally, I think excellence is a virtue in tooling in and of itself. The Python world just hasn't experienced this kind of excellence before.
rmwaite 2y ago
I have issues with some of Black’s formatting decisions but I’ve also suffered from inconsistent formatting and there is no question in my mind that consistent formatting that I find ugly sometimes is 1000% better than the alternative. And after so many years of dealing with it it’s so refreshing to just “give up” and let the formatter win.
- kstrauser 2y ago
  Same here. I appreciate that Black annoyed everyone on our team about the same amount but in different ways. From the instant we added it, stupid style arguments completely disappeared. Know what I care about more than Black making my own code look less pretty? It making my coworker’s code look less horrid. (And funnily, I’m certain everyone on the team thinks exactly that same thing.)
  - JimDabell 2y ago
    > I appreciate that Black annoyed everyone on our team about the same amount but in different ways. If it did affect people equally, it would be great. Unfortunately, spaces for indentation is an accessibility issue and the Black maintainers are hostile to making this configurable. Normally I am in agreement about minimising configurability, but this isn’t a matter of taste, it is making the Python ecosystem more difficult for some disabled people to participate in. https://github.com/psf/black/issues/2798 https://github.com/psf/black/issues/2798 Fortunately, Ruff makes this configurable, so you don’t have to choose between autoformatting and accessibility any more.
    - sunshowers 2y ago
      Thank you. I've heard this argument before and it seems to be a very strong one. I do have a question, though -- can accessibility tools infer tabs based on visual layout or some other mechanism? It seems like one option is for accessibility tools to transform code into tabs internally, which would make them instantly compatible with the vast majority of existing code that uses spaces. What are the practical barriers to making that happen? And is there a good article that discusses all this in a clear, even-handed fashion?
paulgb 2y ago
Doesn’t Black mostly stick to PEP-8 style? What rules do you consider ugly?
- eesmith 2y ago
  When I write argparse or click, I use one parameter per line, like: parser.add_argument( "--stdout", choices = ("true", "false"), default = "true", help = "log data to stdout" ) Black turns it into: parser.add_argument( "--stdout", choices=("true", "false"), default="true", help="log data to stdout" ) I find the one-line-per-term easier to understand, and even though it fits on a single line, I would rather have all add_argument()/@click.option() calls follow the same layout, to make it easier to discern the structure across dozens of similar calls. I also like to have spaces around the "=" in my keyword=arguments, except for very short and simple calls. PEP 8 says "Don’t use spaces around the = sign when used to indicate a keyword argument" so black is following that recommendation. However, everywhere else in the PEP (assignment like 'x = 5', and annotations like 'class Spam: foo: int = 4' or 'def spam(foo: int = 4)', there are spaces on either side of the equals sign. That irritates me every time I have to use black.
  - tda 2y ago
    add a comma after he last argument to make black explicitly use multi-line formatting parser.add_argument( "--stdout", choices=("true", "false"), default="true", help="log data to stdout", ) It also removed the superfluous spaces in the keyword arg assignments
    - L3viathan 2y ago
      The point they're trying to make, I think, is: Black/Ruff format, or any other formatter necessarily need to operate on universal rules. In context, sometimes these rules don't make sense. I still would love some kind of stateful linter and formatter, where it suggests me changes that I can then accept or ignore (and won't be told about again). Formatters _are_ a compromise. They make your coworkers' code nicer, and your code worse.
ak217 2y ago
I don't know what kinds of codebases you've worked with, but I can tell you that pylint is so far from instant, it became the longest running CI job in multiple reasonably sized codebases I've worked with. Think tens of minutes. Other linters were not much better, until ruff came along. But that's far from the only advantage that ruff brings. There are other issues with what you said, but the biggest one is: you have some strongly worded criticism for a project that has set a new bar for usability and consistency in Python code quality tooling. These tools are developed by humans like you and distributed to you for free with no obligation to use them. No matter how I look at your comment, I don't see how it's helping.
- zahlman 2y ago
  I'm confused: why are you linting code in CI, rather than as a precommit hook?
  - ak217 2y ago
    Pre-commit hooks are great in small, focused codebases with small, homogeneous teams. In large monorepos with lots of different teams committing, it's impossible to guarantee any kind of consistency in which pre-commit hooks get run, so you need CI to actually enforce the consistency or you'll spend all your time chasing (accidental) violations.
    - zahlman 2y ago
      ... am I the only one who figures that linting would logically be a very low priority in those circumstances?
      - OrderlyTiamat 2y ago
        Apparently so. Mind explaining your reasoning?
  - kstrauser 2y ago
    Because devs can disable precommit hooks much more easily than they can work around CO. I see precommit hooks as where you avoid the low-hanging fruit, like “is this code actually parsable?”
thayne 2y ago
I like that it's fast, and it is noticeably faster for even moderately sized codebases. But the main thing I like about ruff is that it is a single tool with consistent configuration, as opposed to a combination of several different tools for formatting and linting that each have their own special way of configuring them and marking exceptions to lint rules.
optionalsquid 2y ago
> But all of that personal opinion set aside, what triggers my initial statement is that so many persons are so excited to run to use Ruff because... "It is so fast"... when I'm quite sure most of them would never notice any real speed difference with their modest codebase. I work on a fairly modest code base (22k lines of python according to sloccount), and I'm seeing a significant decrease in runtime between `pylint src/ tests/` with default parameters and `ruff check src/ tests/` with the majority of checks enabled. More specifically, I'm seeing a decrease from 18 second to less than a tenth of a second with a hot FS and having deleted the ruff cache between runs.

Terretta 2y ago

> quite sure most of them would never notice any real speed difference with their modest codebase On the contrary, within only a year or so of coding by a small team, this ecosystem takes single digit seconds or less, while the traditional tools are taking minutes and more. Particularly in analytics or scientific computing we've seen minutes versus under a second. Having the tools not require additional/parallel Python dependency management is a plus. Note that we watched these tools for a long time, and jumped in when rye converged with uv. It was promising to see fewer ways to do it. // More on that here: https://news.ycombinator.com/item?id=41309072 https://news.ycombinator.com/item?id=41309072

sunshowers 2y ago

Personally, I think excellence is a virtue in tooling in and of itself. The Python world just hasn't experienced this kind of excellence before.

rmwaite 2y ago

I have issues with some of Black’s formatting decisions but I’ve also suffered from inconsistent formatting and there is no question in my mind that consistent formatting that I find ugly sometimes is 1000% better than the alternative. And after so many years of dealing with it it’s so refreshing to just “give up” and let the formatter win.

kstrauser 2y ago
Same here. I appreciate that Black annoyed everyone on our team about the same amount but in different ways. From the instant we added it, stupid style arguments completely disappeared. Know what I care about more than Black making my own code look less pretty? It making my coworker’s code look less horrid. (And funnily, I’m certain everyone on the team thinks exactly that same thing.)
- JimDabell 2y ago
  > I appreciate that Black annoyed everyone on our team about the same amount but in different ways. If it did affect people equally, it would be great. Unfortunately, spaces for indentation is an accessibility issue and the Black maintainers are hostile to making this configurable. Normally I am in agreement about minimising configurability, but this isn’t a matter of taste, it is making the Python ecosystem more difficult for some disabled people to participate in. https://github.com/psf/black/issues/2798 https://github.com/psf/black/issues/2798 Fortunately, Ruff makes this configurable, so you don’t have to choose between autoformatting and accessibility any more.
  - sunshowers 2y ago
    Thank you. I've heard this argument before and it seems to be a very strong one. I do have a question, though -- can accessibility tools infer tabs based on visual layout or some other mechanism? It seems like one option is for accessibility tools to transform code into tabs internally, which would make them instantly compatible with the vast majority of existing code that uses spaces. What are the practical barriers to making that happen? And is there a good article that discusses all this in a clear, even-handed fashion?

paulgb 2y ago

Doesn’t Black mostly stick to PEP-8 style? What rules do you consider ugly?

eesmith 2y ago
When I write argparse or click, I use one parameter per line, like: parser.add_argument( "--stdout", choices = ("true", "false"), default = "true", help = "log data to stdout" ) Black turns it into: parser.add_argument( "--stdout", choices=("true", "false"), default="true", help="log data to stdout" ) I find the one-line-per-term easier to understand, and even though it fits on a single line, I would rather have all add_argument()/@click.option() calls follow the same layout, to make it easier to discern the structure across dozens of similar calls. I also like to have spaces around the "=" in my keyword=arguments, except for very short and simple calls. PEP 8 says "Don’t use spaces around the = sign when used to indicate a keyword argument" so black is following that recommendation. However, everywhere else in the PEP (assignment like 'x = 5', and annotations like 'class Spam: foo: int = 4' or 'def spam(foo: int = 4)', there are spaces on either side of the equals sign. That irritates me every time I have to use black.
- tda 2y ago
  add a comma after he last argument to make black explicitly use multi-line formatting parser.add_argument( "--stdout", choices=("true", "false"), default="true", help="log data to stdout", ) It also removed the superfluous spaces in the keyword arg assignments
  - L3viathan 2y ago
    The point they're trying to make, I think, is: Black/Ruff format, or any other formatter necessarily need to operate on universal rules. In context, sometimes these rules don't make sense. I still would love some kind of stateful linter and formatter, where it suggests me changes that I can then accept or ignore (and won't be told about again). Formatters _are_ a compromise. They make your coworkers' code nicer, and your code worse.

ak217 2y ago

I don't know what kinds of codebases you've worked with, but I can tell you that pylint is so far from instant, it became the longest running CI job in multiple reasonably sized codebases I've worked with. Think tens of minutes. Other linters were not much better, until ruff came along. But that's far from the only advantage that ruff brings. There are other issues with what you said, but the biggest one is: you have some strongly worded criticism for a project that has set a new bar for usability and consistency in Python code quality tooling. These tools are developed by humans like you and distributed to you for free with no obligation to use them. No matter how I look at your comment, I don't see how it's helping.

zahlman 2y ago
I'm confused: why are you linting code in CI, rather than as a precommit hook?
- ak217 2y ago
  Pre-commit hooks are great in small, focused codebases with small, homogeneous teams. In large monorepos with lots of different teams committing, it's impossible to guarantee any kind of consistency in which pre-commit hooks get run, so you need CI to actually enforce the consistency or you'll spend all your time chasing (accidental) violations.
  - zahlman 2y ago
    ... am I the only one who figures that linting would logically be a very low priority in those circumstances?
    - OrderlyTiamat 2y ago
      Apparently so. Mind explaining your reasoning?
- kstrauser 2y ago
  Because devs can disable precommit hooks much more easily than they can work around CO. I see precommit hooks as where you avoid the low-hanging fruit, like “is this code actually parsable?”

thayne 2y ago

I like that it's fast, and it is noticeably faster for even moderately sized codebases. But the main thing I like about ruff is that it is a single tool with consistent configuration, as opposed to a combination of several different tools for formatting and linting that each have their own special way of configuring them and marking exceptions to lint rules.

optionalsquid 2y ago

> But all of that personal opinion set aside, what triggers my initial statement is that so many persons are so excited to run to use Ruff because... "It is so fast"... when I'm quite sure most of them would never notice any real speed difference with their modest codebase. I work on a fairly modest code base (22k lines of python according to sloccount), and I'm seeing a significant decrease in runtime between `pylint src/ tests/` with default parameters and `ruff check src/ tests/` with the majority of checks enabled. More specifically, I'm seeing a decrease from 18 second to less than a tenth of a second with a hot FS and having deleted the ruff cache between runs.