yapf v0.24.0 formatts my dict like this:
_CUSTOMER_ENRICHMENT_TAGS = [
{
'name': '@{user.first_name}',
'extractor': lambda customer: customer.current_user_details.first_name
},
{
'name': '@{user.last_name}',
'extractor': lambda customer: customer.current_user_details.last_name
}, {
'name': '@{user.user_name}',
'extractor': lambda customer: customer.user_name
},
{
'name': '@{user.email}',
'extractor': lambda customer: customer.current_user_details.email_address
}
]
The third item's opening { starts on the same line as the previous items' closing }. But only that one.
I can't of a reason why it would do that.
Our .style.yapf:
[style]
align_closing_bracket_with_visual_indent=True
allow_multiline_dictionary_keys=False
allow_multiline_lambdas=False
allow_split_before_dict_value=True
blank_lines_around_top_level_definition=2
blank_line_before_class_docstring=False
blank_line_before_module_docstring=False
blank_line_before_nested_class_or_def=False
coalesce_brackets=True
column_limit=100
continuation_align_style=SPACE
continuation_indent_width=4
dedent_closing_brackets=True
disable_ending_comma_heuristic=False
each_dict_entry_on_separate_line=True
i18n_comment=
i18n_function_call=
indent_dictionary_value=True
indent_width=4
join_multiple_lines=True
no_spaces_around_selected_binary_operators=
spaces_around_default_or_named_assign=False
spaces_around_power_operator=False
spaces_before_comment=2
space_between_ending_comma_and_closing_bracket=True
split_all_comma_separated_values=False
split_arguments_when_comma_terminated=False
split_before_bitwise_operator=True
split_before_closing_bracket=True
split_before_dict_set_generator=True
split_before_dot=False
split_before_expression_after_opening_paren=False
split_before_first_argument=False
split_before_logical_operator=True
split_before_named_assigns=True
split_complex_comprehension=False
split_penalty_after_opening_bracket=30
split_penalty_after_unary_operator=10000
split_penalty_before_if_expr=0
split_penalty_bitwise_operator=300
split_penalty_comprehension=80
split_penalty_excess_character=7000
split_penalty_for_added_line_split=30
split_penalty_import_names=0
split_penalty_logical_operator=300
use_tabs=False
Syntactically the same. this almost doesn't matter, but is an easy fix PR.
How do you mean it almost doesn't matter?
It's not a syntactic error.... Javascript doesn't 'care' about whitespace,
so though it will look more uniform, it won't change the program's
behavior.
On Thu, Nov 22, 2018, 4:25 AM Jan Hancic How do you mean it almost doesn't matter? —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/yapf/issues/642#issuecomment-440966020, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AbaF5O_dkU_ns0vvHfBYxG0WKpwwxk_8ks5uxm2BgaJpZM4YUPHV
.
yapf is a Python formatter, the code above is Python, not JavaScript.
Regardless, you are right, this isn't a syntax error. But the formatter of code (which is what yapf is) is producing inconsistent results. So it does matter.
Python should never use curly braces.... Delete 'em all.
On Thu, Nov 22, 2018, 9:17 AM Jan Hancic <[email protected] wrote:
yapf is a Python formatter, the code above is Python, not JavaScript.
Regardless, you are right, this isn't a syntax error. But the formatter of
code (which is what yapf is) is producing inconsistent results. So it does
matter.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/yapf/issues/642#issuecomment-441043788, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AbaF5DMpx6XTBIQGx__XDiRmCSjSWiqKks5uxrIQgaJpZM4YUPHV
.
Maybe becuase of This
YAPF tries very hard to get the formatting correct. But for some code, it won't be as good as hand-formatting. In particular, large data literals may become horribly disfigured under YAPF.
The reasons for this are manyfold. In short, YAPF is simply a tool to help with development. It will format things to coincide with the style guide, but that may not equate with readability.
Which was mentioned in the Readme.md That it is simply a tool to help devs and can cause errors.
Thank You.
I'm seeing a similar thing with dict formatting.
If I start with this poorly formatted dict:
MODEL_LIST = { 'episode': { 'model': FMPEpisode, 'method': ingest_episode_list, 'options': {} },
'event': { 'model': FMPEvent, 'method': ingest_event_list, 'options': {} },
'season': { 'model': FMPSeason, 'method': ingest_season_list, 'options': {} },
'table': { 'model': FMPTable, 'method': ingest_table_list, 'options': {}
}
}
yapf formats it like so:
MODEL_LIST = {
'episode':
{
'model': FMPEpisode,
'method': ingest_episode_list,
'options': {}
},
'event': {
'model': FMPEvent,
'method': ingest_event_list,
'options': {}
},
'season': {
'model': FMPSeason,
'method': ingest_season_list,
'options': {}
},
'table': {
'model': FMPTable,
'method': ingest_table_list,
'options': {}
}
}
If I add commas to the final items in each nested dict, yapf then formats like this:
MODEL_LIST = {
'episode':
{
'model': FMPEpisode,
'method': ingest_episode_list,
'options': {},
},
'event': {
'model': FMPEvent,
'method': ingest_event_list,
'options': {},
},
'season':
{
'model': FMPSeason,
'method': ingest_season_list,
'options': {},
},
'table': {
'model': FMPTable,
'method': ingest_table_list,
'options': {},
}
}
My config is very simple:
[style]
based_on_style=facebook
align_closing_bracket_with_visual_indent=True
There's been recent changes to dictionary formatting. Are you seeing this with top-of-tree?
I installed the current master (8871cf6f6cb0838685cbce0df2263b780c410b1a) and my example dict gets formatted much nicer now:
MODEL_LIST = {
'episode': {
'model': FMPEpisode,
'method': ingest_episode_list,
'options': {},
},
'event': {
'model': FMPEvent,
'method': ingest_event_list,
'options': {},
},
'season': {
'model': FMPSeason,
'method': ingest_season_list,
'options': {},
},
'table': {
'model': FMPTable,
'method': ingest_table_list,
'options': {},
}
}