Interestingly, the question whether this particular choice of code formatting in black adheres to pep8 is still an ongoing discussion[1][2][3][4]. Guido, for example, thinks that black's choice is not compatible with pep8 and I think he described the situation quite well on Python's Discourse[5]:
> So the root of this argument is that Black produces code that isn’t always in compliance with PEP 8. I say this is fine – if you use Black you don’t need PEP 8 to tell you how to format your code. (PEP 8 is still useful for other things like naming things.)
> Black optimizes for a different goal than PEP 8; PEP 8 optimizes for readability while Black sometimes compromises readability in order to satisfy other goals such as minimizing lines changed as code evolves.
Thanks for the pointers, I stand corrected. OP could continue this debate if that’s his passion. I bow out.
Meanwhile, I’ll happily enforce black where I can so that I don’t need to have these pointless arguments, although I personally strongly disagree with many of its decisions. I also have no problem contributing to whatever non-blackened projects, including CPython itself (contributed quite a few patches over the years), which is probably the final word on PEP8.
> so that I don’t need to have these pointless arguments
This. I can't believe how much time is lost in such discussions. To paraphrase cjbprime from 11 months ago [1], "nobody likes what the code-formatter does to their code, but everybody likes what it does to their coworker's."
Meanwhile, I’ll happily enforce black where I can so that I don’t need to have these pointless arguments, although I personally strongly disagree with many of its decisions. I also have no problem contributing to whatever non-blackened projects, including CPython itself (contributed quite a few patches over the years), which is probably the final word on PEP8.