How to deal with ugly code formatter output? (Black) [closed]

Question

I'm currently experimenting with the Black code formatter for Python. In >90% of the cases I am happy with the output (with default configs), but it regularly happens, that it formats some lines in a way that seems rather ugly to me.

Here an example, before and after formatting with black.

Before:

After:

The syntax of these two lines is originally identical (same function, same number of arguments...), so it makes sense to format them in the same way. However, as the first line is slightly longer, Black formats it differently, which makes it much more difficult to read and interpret the code.

Of course, in this particular case, you could just increase the linelength parameter of Black, but that doesn't really solve the problem in general, and I would like to stick with the default configuration.

I have come across many such situations, also using other formatters such as Prettier for JavaScript. How do you handle these situations? Is there for example a way to tell Black, to ignore these particular lines and not format them?

Grasshopper

"I would like to stick with the default configuration" - well you're going to have to reconfigure something if you want different output. – Matador

I don't think there is a configuration that prevents 100% of these cases, where the output is formatted in a suboptimal way. One of the main objectives of these tools is to guarantee uniform code formatting styles among different developers. This objective can clearly not be met if every developer uses another configuration. resulting in another format. – Grasshopper

@roganjosh: surely a code prettyfier is a tool commonly used by programmers! – Rimola

@usr2564301 fair enough, I'll retract. – Corrida

@usr2564301: FWIW, most programmers I've known seldom, if ever, use prettyfiers—and I've known quite a few of them having been in the IT industry for a long time... – Ouzo

@martineau: neither have I. But Stack Overflow is for both "professional and enthousiast programmers", and this goes for their toolkit as well. 😊 – Rimola

@Ouzo The Prettier extension in VS code has close to 6 million downloads. I also have been reading more and more blog posts on how awesome code formatters are (although never commenting the problems I outlined in the question). So there has to be a quite large userbase, or am I mistaken? – Grasshopper

nkaenzig: The Black documentation says "It is not configurable", so it sounds like you're stuck with whatever it does. On the other hand its source code is available—so theoretically you could change that. – Ouzo

nkaenzig: downloads ≠ usage. It's possible many folks don't actually use prettyfiers because none of them does a good enough job in all cases—as appears to be the case here. – Ouzo

@Ouzo downloads ≠ usage is a fair point. However, if most of the users that download the tool were unsatisfied and in consequence didn't use it, this should also result in a large number of bad ratings, which is not the case (at least for the Prettier extension in VS Code) – Grasshopper

@nkaenzig: Possibly. Maybe its good rating is because it works most of the time. ;¬) – Ouzo

may be we can give a try to yapf github.com/google/yapf#id12 instead of black – Crissum

Just a side note, if you add a "dangling" comma after "recall", black will format the second statement's arguments the way you are wanting (on separate lines). Not saying that this addresses the real problem... just pointing out that there are ways to hint to black what to do. – Parcae