PEP-8: clarify if multiline argument list with a closing `)` on a separate line is acceptable

PEPs
21

Hi Philip,

You wrote:

“I do think PEP-8 clearly rejects ): tabbed in on trailing lines.”

Do you mean tabbing out here?

It can’t be that clear if we need to argue about it. If PEP 8 clearly
said something like:

“Do not tab in (out?) on ): lines”

then there would be no room for argument. But it doesn’t, not so far as
I can see. (Perhaps I missed something?)

You wrote:

“There’s a clear difference between “}” tabbed out and “):” tabbed
out. And it’s this: In a dictionary the definition starts where you tab
in and ends where you tab out”

That’s incorrect. The dictionary ends at the closing brace },
regardless of whether you tab in, tab out, or neither.

You had this code snippet:

foo = {
    # Thing has started
    'x': 1,
    'y': 2,
} 
# Thing has finished.

(By the way, I wouldn’t write it like that. First, I would tab in by
two levels, not one, to make it clear that this isn’t a code block
indent; and second I would either align the closing tab with the
double-indented block, or place it on the same line as the final key.)

But the comment is inaccurate: the “thing” (dict) ended on the previous
line, and not because of the outdent, but because of the brace. So I
think your argument is irrelevant.

I agree with you that outdenting the brace is not visually attractive,
and I wouldn’t write it like that, but I don’t think that it has
anything to do with an outdent signalling “thing has finished” or not.
Outdenting signals the end of a block statement, not arbitrary groupings
of code such as tuples, dicts, or parameter lists in a function def.

Since I don’t agree that this outdent “rule” applies to anything except
block statements, where it is enforced by the compiler, I don’t think
that this:

def foo(
   # thing has started
   bar
# thing has finished ... oh no wait...
):

breaks the rule. But I do agree that it is ugly.

For what it’s worth, the “thing” here that finishes at the colon is the
function header def funcname(parameter list):, and the body doesn’t
start until the block beginning with an indent.

23

@steven.daprano I think you missed my point entirely. Yes a dictionary ends syntactically on the closing brace. This is true no matter how “bad” your formatting. My point was on the subject of cognitive dissonance between the shape the tabbing pattern and the strict semantic meaning of the syntax…

…That is to say tabbing patterns create affordances. When you see a shape in tabbing style it gives your eye some meaning about the content. For some of us, that affordance (visual meaning) is much faster to interpret than the syntax itself. For others the dissonance between the semantic meaning and the “visual meaning” creates a sense of “ugly”. Far from being irrelevant, “bad” tabbing is a real problem and not simply a matter of “ugly” or “pretty”, but because it dramatically slows down some readers and can in some cases cause coding errors.

My point was that in all of python and the style guide(s), the affordances (visual meaning) tend to be closely aligned with the strict semantic interpretation of the syntax. Importantly they are very consistent in which shape goes with which semantic meaning. This remains true even when you tab left a close } on a dictionary. But it does NOT remain true when a close ): is tabbed left.

Now if this tabbing pattern was completely consistent (we always did that for ):), there would be a less of a problem. But we don’t. We never use this tab left before the end of a block in any other context and the suggestion on this thread (AKA Black formatting) is to only use this in exceptional cases where the line is too long to do otherwise.

Far from irrelevant or just “ugly”, it’s creating cognitive dissonance that doesn’t exist anywhere else in python or its style guides.

24

Hi Philip,

I didn’t miss your point, I just disagree with your analysis.

But in the big picture, I don’t know what you want here. It sounds to me
like you are in dispute with colleagues over formatting, and you want
PEP 8 to take your side by banning the outdenting of ): in a function
signature.

What is it that you want? Is there some std lib code you want changed?
Do you want a change to PEP 8? If PEP 8 already says what you want it to
say, what’s the purpose of this discussion?

25

Hi Steven

Please don’t make personal attacks. My comments were entirely in response to the content of this thread.

I had chosen to delete my comments in preference for refactoring them and putting them elsewhere. However they were responded to (by you) 17 hours after I deleted them. I felt it better to restore them for the sake of future readers.