5 ms·

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

by paulgb 2y ago

eesmith 2y ago
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.
- 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 ago
    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
    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".
    - tda 2y ago
      you 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 ago
        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.

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

by paulgb 2y ago

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.

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 ago
  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
  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".
  - tda 2y ago
    you 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 ago
      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.