"INTERNAL ERROR: Black produced different code on the second pass of the formatter" #1629
Description
- Version: 20.8b0
- OS and Python version: all
This is a rare problem that we're currently investigating. The most common case of it has to do with a combination of magic trailing commas and optional parentheses. Long story short, there's this behavior:
- Black now treats all pre-existing trailing magic commas found in bracket pairs as signal to explode that bracket pair (e.g. to format it "one element per line");
- in other places Black inserts trailing commas itself after reformatting a long expression or statement;
- then on another run, Black finds those trailing commas and treats them as pre-existing trailing commas that signal that the given bracket pair should be exploded.
The expected behavior is that there should be no difference between the first formatting and the second formatting. In practice Black sometimes chooses for or against optional parentheses differently depending on whether the line should be exploded or not. This is what needs fixing.
Workaround
We're working on fixing this, until then, format the file twice with --fast
, it will keep its formatting moving forward.
Call To Action
If you find a case of this, please attach the generated log here so we can investigate. We've already added three identifying examples of this as expected failures to 25206d8.
Finally, if you're interested in debugging this yourself, look for should_explode
in if
statements in the Black codebase. Those are the decisions that lead to unstable formatting.