I usually prefer a set of dead-simple formatting/styling rule, easier to enforce, lower cognitive load.
I usually prefer a set of dead-simple formatting/styling rule, easier to enforce, lower cognitive load.
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).
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.
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.
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.