4 ms·

I like the spirit of it, but the implementation seems to contain too many exceptions (e.g. trailing comma, whilespaces around :). This problem is not unique to

by abakus 8y ago

I like the spirit of it, but the implementation seems to contain too many exceptions (e.g. trailing comma, whilespaces around :). This problem is not unique to Black, it is actually too common for most auto-formatters. I usually prefer a set of dead-simple formatting/styling rule, easier to enforce, lower cognitive load.

ambivalence 8y ago
What don't you like about the exceptions? The code and the documentation would both be simpler without them. They are there because the end result is closer to what a human would do in those situations. And the two exceptions you mentioned are ones you will also have to make if you want to stay PEP 8 compliant (pycodestyle's E203 is invalid inside slices) and you want your code to execute on Python pre-3.6 (where you can't add trailing commas to calls and signatures containing args and *kwargs).
- fishywang 8y ago
  > where you can't add trailing commas to calls and signatures containing args and kwargs I think that's signature only. You don't have problems with calls: $ python3.5 Python 3.5.5 (default, May 17 2018, 07:04:26) [GCC 7.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def foo(*args, **kwargs): ... print(*args, **kwargs) ... >>> foo( ... 'abc', ... ) abc >>> The argument black made about not adding trailing comma is also quite unconvincing to me: > Unnecessary trailing commas are removed if an expression fits in one line. This makes it 1% more likely that your line won't exceed the allotted line length limit. Moreover, in this scenario, if you added another argument to your call, you'd probably fit it in the same line anyway. That doesn't make diffs any larger. Who cares about the 1% chance of not exceeding the line length limit? If you really care about that, use one-per-line style, not all arguments in one new line.
  - ambivalence 8y ago
    Yeah, call side was fixed in 3.5 but I don't split hairs here. I consider it either 3.6+ or don't put trailing commas after neither signatures nor calls with stars. BTW, your signature doesn't demonstrate a call with unpacking. What you meant to test was: l = [1, 2, 3] foo(0, *l,) This works in 3.5+ but fails on 3.4 and before.
revfried 8y ago
using black is the no cognitive load in my book.
vjeux 8y ago
The reality is that the way humans write code is complex and if you try to use simple rules it's going to look bad in many cases. What linters have been doing is to figure out --some-- rules that are general enough that can be enforced. Complete formatters like black are making decisions for --every single formatting choices--. In practice, they need to be complex if they want to have people using them.

by abakus 8y ago

ambivalence 8y ago

What don't you like about the exceptions? The code and the documentation would both be simpler without them. They are there because the end result is closer to what a human would do in those situations. And the two exceptions you mentioned are ones you will also have to make if you want to stay PEP 8 compliant (pycodestyle's E203 is invalid inside slices) and you want your code to execute on Python pre-3.6 (where you can't add trailing commas to calls and signatures containing args and *kwargs).

fishywang 8y ago
> where you can't add trailing commas to calls and signatures containing args and kwargs I think that's signature only. You don't have problems with calls: $ python3.5 Python 3.5.5 (default, May 17 2018, 07:04:26) [GCC 7.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def foo(*args, **kwargs): ... print(*args, **kwargs) ... >>> foo( ... 'abc', ... ) abc >>> The argument black made about not adding trailing comma is also quite unconvincing to me: > Unnecessary trailing commas are removed if an expression fits in one line. This makes it 1% more likely that your line won't exceed the allotted line length limit. Moreover, in this scenario, if you added another argument to your call, you'd probably fit it in the same line anyway. That doesn't make diffs any larger. Who cares about the 1% chance of not exceeding the line length limit? If you really care about that, use one-per-line style, not all arguments in one new line.
- ambivalence 8y ago
  Yeah, call side was fixed in 3.5 but I don't split hairs here. I consider it either 3.6+ or don't put trailing commas after neither signatures nor calls with stars. BTW, your signature doesn't demonstrate a call with unpacking. What you meant to test was: l = [1, 2, 3] foo(0, *l,) This works in 3.5+ but fails on 3.4 and before.

revfried 8y ago

using black is the no cognitive load in my book.

vjeux 8y ago

The reality is that the way humans write code is complex and if you try to use simple rules it's going to look bad in many cases. What linters have been doing is to figure out --some-- rules that are general enough that can be enforced. Complete formatters like black are making decisions for --every single formatting choices--. In practice, they need to be complex if they want to have people using them.