News for hackers. Stuff that matters.
Re:Black: An uncompromising Python code formatter by abakus on Friday May 25, 2018 @12:30PM (#17155318)
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.

Re:Black: An uncompromising Python code formatter by ambivalence on Friday May 25, 2018 @12:39PM (#17155404)
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).

Re:Black: An uncompromising Python code formatter by fishywang on Friday May 25, 2018 @07:14PM (#17158932)
> 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.

Re:Black: An uncompromising Python code formatter by ambivalence on Friday May 25, 2018 @08:29PM (#17159319)
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.

Re:Black: An uncompromising Python code formatter by revfried on Friday May 25, 2018 @12:43PM (#17155434)
using black is the no cognitive load in my book.
Re:Black: An uncompromising Python code formatter by vjeux on Friday May 25, 2018 @12:56PM (#17155577)
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.