3 ms·
add a comma after he last argument to make black explicitly use multi-line formatting parser.add_argument( "--stdout", choices=("true", "false"),
by 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 agoThe 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 agoThe 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 agoThe 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 agoYes, 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 agoSweet! 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".
- tda 2y agoyou can discuss the spaces and lack there of here: https://stackoverflow.com/questions/8853063/pep-8-why-no-spaces-around-in-keyword-argument-or-a-default-parameter-value https://stackoverflow.com/questions/8853063/pep-8-why-no-spa... The rest of us just follow the PEP8 style guide and move on
- eesmith 2y agoThe 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.