-
Notifications
You must be signed in to change notification settings - Fork 891
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
Comprehensions should not split between tuple-unpacking commas #756
Comments
I just noticed the same thing happens with lambda expressions. YAPF formatted code:
|
I'd like to comment that this also happens with |
Still present in v0.31.0. The same goes for lambdas in dictionaries, see #662 Summarizing, with func_called_with_lambda_args('some long string',
'some very long string',
lambda arg1, arg2: arg1 + arg2)
dict_with_lambdas = {
'difference': lambda val1, val2: val1 - val2,
lambda val1, val2: val1 * val2: 'product'
}
dict_comprehension_with_unpacking = {
field_name: func(field_value)
for field_name, field_value in fields.items()
} is formatted to func_called_with_lambda_args('some long string',
'some very long string',
lambda arg1,
arg2: arg1 + arg2)
dict_with_lambdas = {
'difference': lambda val1,
val2: val1 - val2,
lambda val1,
val2: val1 * val2: 'product'
}
dict_comprehension_with_unpacking = {
field_name: func(field_value)
for field_name,
field_value in fields.items()
} |
Re-surfacing this via #1159 as well. Since this issue is there for years, it seems that there's no solid opinion on how it's supposed to work? |
I think it's clear what the intent is: tuples that are part of a unit for unpacking purposes (and arguably lambda arguments fall in the same boat) should bind more tightly. That's not saying it's clear what the implementation should be. |
@robertwb I don't think that's the case since if we take a look at SPLIT_ALL_COMMA_SEPARATED_VALUES definition, it clearly says:
The current implementation neither checks for length, or for node type: yapf/yapf/yapflib/format_decision_state.py Lines 182 to 183 in 64f8b1b
so that values = [
lambda a, b: a + b,
] becomes values = [
lambda a,
b: a + b,
] So if the implementation was at least somehow close to the description, it would seem that the issue were less severe if existed at all. |
Agreed that this is gross. The knob needs to be relaxed a bit to avoid splitting in such cases...I'll see what can be done. |
Could you try this patch to see if it helps and doesn't have any bad side effects?
|
@bwendling thanks for the diff! My test-case remained unaffected by the change, I'll debug into that. Update: Ah, I see - a bit of code reshuffling is needed, PR coming soon. |
split_all_top_level_comma_separated_values
inserts spurious breaks between commas in tuple-unpacking expressions in comprehensions.Hand-formatted code:
YAPF changes this to:
The third line is short enough to fit within the line limit without breaking, and putting a break there decreases readability. I can't see any logical reason there should be a break there.
If I turn off
split_all_top_level_comma_separated_values
, YAPF does not change my hand-formatted code.Full configuration:
The text was updated successfully, but these errors were encountered: