Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

single-member multi-line expressions and trailing commas #493

Closed
mattsb42-aws opened this issue Aug 30, 2018 · 4 comments
Closed

single-member multi-line expressions and trailing commas #493

mattsb42-aws opened this issue Aug 30, 2018 · 4 comments
Labels
F: trailing comma Full of magic T: style What do we want Blackened code to look like?

Comments

@mattsb42-aws
Copy link

Operating system: MacOS
Python version: 3.7.0
Black version: 18.6b4
Does also happen on master: yes

I can't quite tell if this is intended behavior or if it is emergent behavior caused by other things.

I noticed this because black and isort (configured with multi_line_output = 3 and include_trailing_comma = True) started fighting over a particular line.

Per the trailing comma rules, it it my understanding that all multi-member expressions defined over multiple lines should have a trailing comma at the end of each member line, but expressions that fit on a single line and do not syntactically require a trailing comma will have that trailing comma removed.

This is good, and in my experience this is what black does. However, there is an edge case that is not directly addressed in the rules in the readme: an expression that can contain multiple members but only contains a single member and cannot fit on a single line.

Based on my understanding of the reason behind the adding trailing commas to the end of multi-line expression members (making diffs less bad), I would think that the single member in these cases should still have a trailing comma.

However, based on the "remove trailing commas on single line expressions unless syntactically necessary" exception, the trailing comma should not be present.

The behavior that black applies follows the rules that would be followed if the expressions were contained on a single line. Is this intentional? If so, could a mention of this exception be added to the readme?

input:

from long_namespace_that_makes_the_line_too_line import (
    long_variable_name,
)


long_namespace_that_makes_the_line_too_line = (
    long_variable_name,
)


long_namespace_that_makes_the_line_too_line = [
    long_variable_name,
]


long_namespace_that_makes_the_line_too_line = {
    "foo": long_variable_name,
}


long_namespace_that_makes_the_line_too_line = {
    long_variable_name,
}

output:

from long_namespace_that_makes_the_line_too_line import (
    long_variable_name
)


long_namespace_that_makes_the_line_too_line = (
    long_variable_name,
)


long_namespace_that_makes_the_line_too_line = [
    long_variable_name
]


long_namespace_that_makes_the_line_too_line = {
    "foo": long_variable_name
}


long_namespace_that_makes_the_line_too_line = {
    long_variable_name
}
@zsol zsol added T: style What do we want Blackened code to look like? F: trailing comma Full of magic labels Sep 7, 2018
@zsol
Copy link
Collaborator

zsol commented Sep 7, 2018

I think we should document what black does currently, with the caveat that after #250 is fixed, your import example will also have a trailing comma.

@ambv
Copy link
Collaborator

ambv commented May 7, 2019

This will be addressed by #826.

@tucked
Copy link

tucked commented Nov 8, 2019

I think this is still reproducible with 19.10b0 (which appears to include #826).

@ambv
Copy link
Collaborator

ambv commented Mar 3, 2020

Edge cases not covered by #826 will be solved as part of #1288.

@ambv ambv closed this as completed Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: trailing comma Full of magic T: style What do we want Blackened code to look like?
Projects
None yet
Development

No branches or pull requests

4 participants