I haven’t read this entire thread, but I thought folks should be aware that a couple of us have been hacking on a formatter called blue. It’s essentially black (and in fact it’s implementation monkeypatches black) with a limited set of different formatting choices. Our hope is to eventually work with the black maintainers so that we can hook into black or add a small number of configuration settings. blue should at least give options to folks who want to adopt a formatter but aren’t satisfied with all the choices made by black.
9 Likes
I’d rather something like black, but with red stripes.
Well, blue does have an awesome icon! 
1 Like
Indeed, and each reviewer will have an entirely different subset of issues that “really matter”; e.g. one core developer may consider a specific styling rule in PEP 8 to be of significant importance for readability, whereas another will merge the PR without even considering it. One developer’s low hanging fruit is another developer’s cornucopia, even more so considering the wide variety of backgrounds present within the core team.
That being said, I do mostly resonate with the main point I interpreted @ssbarnea to be making, that a code formatter done right should help to remove tedious parts of review. We just have to be careful that it’s limited enough to not step on the proverbial toes of the many existing styles throughout the stdlib, otherwise it would almost certainly result in more harm than good.
CPython is rather unique in the sense that we have an incredibly diverse array of styles within a single repo depending on which particular area or module is in question, unlike most I’ve encountered in the wild which tend to have a more universal style. And I presume we’re mostly all in agreement here that trying to change that would be an endless time sink which would likely result in experts losing track of their code area more than it would yield tangible benefit.
Awesome! I very much hope that blue ends up being a decent compromise. 
3 Likes
I don’t think it matters what auto formatter you use, but my experience on working on auto formatted code bases is very much a positive experience. Not having to think or care about formatting anymore let’s me focus much more time on solving the actual underlying problem.
4 Likes
My single requirement from a code formatting tool is the ability to disable it. For instance, yapf has # yapf: disable and # yapf: enable to protect a section of code from formatting.
The most common reason is to preserve hand formatting which makes data initialization statements more readable, which in turn improves the correctness of initial entry and maintenance.
2 Likes
I’m no Python core dev of course, but the only thing making me accept black in our work codebase is that it support # fmt: off|on directives. That makes it much more useful when you yourself know a more readable way to format the code.
2 Likes