Hacker News Reader

Comment by greatgib | Hacker News Reader

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!

View on HN

> 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

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.

I'm confused: why are you linting code in CI, rather than as a precommit hook?

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.

... am I the only one who figures that linting would logically be a very low priority in those circumstances?

Apparently so. Mind explaining your reasoning?

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?”

Well, for one, I use Jujutsu, where commits happen every time you run jj status and traditional notions of pre-commit hooks don't really apply. But also, I think (as a matter of principle) nothing should get in the way of performing commits or amends.

Depends on what you're trying to achieve. Jobs like lint checks should ideally be pre-push checks so that the long process doesn't get in the way of commits. But very fast and small checks like warning about trailing whitespaces or ensuring a newline at the end of the file can be done during every commit (even if it was in jujutsu). I would rather not wait till the end to find out. And of course, there are ways to temporarily or permanently disable one or more checks when you absolutely need it.

My editor takes care of trailing whitespace and newline termination. I don't think Jujutsu commits should fail on this or fix it every time jj status is run — seems too magical.

Because commits should be small and fast, and always work, like a save. If you’re running a multi second process during commit it’s going to get ripped out.

Ahah! I worked on a project which used dotnet format in a commit hook. That was a frustrating experience, trying to rebase code.

(Unlike most formatters which are instant, dotnet format takes at least half a minute, because it performs a build just to format your code.)

My thinking is that the linter only has to operate on the code that was actually checked in. And just how many things are you checking about it, anyway?

Can you tell us a little bit more about your codebase? I'm curious. Because for it to take tens of minutes, something should be crazy over there.

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.

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.)

> 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

Fortunately, Ruff makes this configurable, so you don’t have to choose between autoformatting and accessibility any more.

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?

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.

> 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.

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.

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

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.

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

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.

The point I was trying to make is to give examples of rules I thought were ugly, to give a concrete response to paulgb's request for such a rule.

One, as I learned, could be resolved by a simple use of a terminal ",".

The other is how it removes spaces from around "=" for keyword arguments, but not for other uses of "=".

I can't provide much more as I rarely use black. As a single developer, I don't have to worry much about that sort of compromise. ;)

The removal of spaces around keyword arguments is per the PEP8 style guide. There is no point arguing with the style guide. It is there to end discussions. I also do not agree with everything in the style guide. But I keep that to myself. Because a single universal (but flawed) style guides >> competing style guides >> complete anarchy

Yes, I even pointed out how it's in PEP 8.

That I think it's wrong and ugly is an entirely different point.

PEP 8 specifically says it it not universal:

> Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project. ...

> However, know when to be inconsistent – sometimes style guide recommendations just aren’t applicable. When in doubt, use your best judgment. ...

> Some other good reasons to ignore a particular guideline:

> When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.

I think always omitting spaces there makes it less readable, even for someone who is used to reading PEP 8.

That makes me more compliant to PEP 8 than black. ;)

Sweet! Thanks! I did not know that, and I've no problem with a terminal comma there.

My point stands - I do not think those spaces are superfluous. Consider the following:

    a = 4

    def foo(i: int):
        return "A" * i

    class Spam:
        foo = 4
        bar: int = 6

        def eggs(self, n: int = 5):
            return foo(i=n)

Why is it "i=n" instead of "i = n" when every other use of "=" has spaces?

For this one case of a short function with simple names, okay, I don't always use spaces.

But otherwise I think the lack of spaces makes it the code harder to read, and thus "uglier".

you can discuss the spaces and lack there of here: https://stackoverflow.com/questions/8853063/pep-8-why-no-spa...