3 ms·

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 t

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.

eesmith 2y ago
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. ;)
- tda 2y ago
  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
  - eesmith 2y ago
    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. ;)

eesmith 2y ago

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

tda 2y ago
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
- eesmith 2y ago
  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. ;)