On: EditorConfig: Consistent coding styles across vari...

[ambivalence]

This experience must have been with a formatter different than Black. That one has no problems with any valid syntax.

[tom_ → ambivalence]

I think the point is that the valid python syntax is potentially a limitation on any autoformatting tool. Like, suppose you were writing in C. You might well write this:

    if(x);else if(y){if(z);else;}

and clang-format would turn it into this:

    if(x) {
    } else if(y) {
        if(z) {
        } else {
        }
    }

But the equivalent in Python has to be correctly indented to be interpreted properly, because you need to distinguish these two cases:

    if x: pass                 if x: pass
    elif y:                    elif y:
        if x: pass                 if x: pass
    else: pass                     else: pass

(This is the classic shift/reduce problem: https://www.gnu.org/software/bison/manual/html_node/Shift_00...)

This is sort-of not unreasonable, because of course code has to be syntactically correct for the autoformatter to do its thing, and if you're working in Python, these are the syntax rules. So, what can you do?

But suppose you'd come to find it valuable to be able to stuff all your code on one line and have the autoformatter sort it out: you might then find the Python syntax a backwards step by comparison, rather than an improvement. I think this is the claim that's being made, and no more.

[samatman → tom_]

It even has a name, the Dangling Else, and dates back to Algol:

https://en.wikipedia.org/wiki/Dangling_else

[dorfsmay → tom_]

This is what I meant, yes, although I could never have explained it half as well as you did!

[fiddlerwoaroof → tom_]

One solution is to make the formatter interactive and prompt for which interpretation is desired.

A CL restart-style editor integration for this could be interesting.