Hacker News Reader

Comment by paulgb | Hacker News Reader

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