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.
> 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.
> I don’t want to compromise PEP 8 though.
[1]: https://github.com/psf/black/issues/48
[2]: https://github.com/psf/black/issues/1178
[3]: https://github.com/psf/black/issues/1336
[4]: https://github.com/PyCQA/pylint/issues/289
[5]: https://discuss.python.org/t/pep-8-clarify-if-multiline-argu...