Hacker News Reader

Comment by tda | Hacker News Reader

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

View on HN

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

The rest of us just follow the PEP8 style guide and move on

The question was 'What rules do you consider ugly?'.

I think that rule is ugly. I explained why.

If you don't like the thread, move on.

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

Reply on news.ycombinator.com