Yapf: Dict formatting with 0.16.1

[retr0h]

Dict formatting seems weird under 0.16.1. The value is added to a new line under the key, this seems somewhat silly, especially when the line length doesn't exceed column_limit. I don't see a tunable to disable this.

[style]
based_on_style = pep8
column_limit = 79

     x = {
-        'ansible_host': '127.0.0.1',
-        'ansible_port': 2222,
-        'ansible_user': 'vagrant',
-        'ansible_private_key_file': '"/foo/bar"',
-        'connection': 'ssh',
+        'ansible_host':
+        '127.0.0.1',
+        'ansible_port':
+        2222,
+        'ansible_user':
+        'vagrant',
+        'ansible_private_key_file':
+        '"/foo/bar"',
+        'connection':
+        'ssh',
         'ansible_ssh_extra_args': ('-o UserKnownHostsFile=/dev/null '
                                    '-o ControlMaster=auto '
                                    '-o ControlPersist=60s '

[retr0h]

Any update?

[rafalp]

Have you tried with 16.2?

[retr0h]

Have you tried with 16.2?

16.2 has the same behavior reported above.

[gwelymernans]

Sorry for the delay in responding. I've been busy with other things. The reason it's doing this is because the last element ('ansible_ssh_extra_args') has a value that goes beyond the column length. The thing is that of course each string is going to be placed on individual lines anyway, so it's not really necessary to place all values on separate lines. (The heuristic we use is if one element's value goes beyond the column limit then all elements will have their values placed on separate lines.)

This can probably be relaxed when looking at implicit string concatenations like this one.

[humitos]

Maybe it's related to #378

[jlowin]

Here's a another example, but caused by something other than concatenation. In this case, the list comprehension would be greater than the column limit IF it were a single line -- but of course it isn't a single line, and is nicely formatted across a few lines. Nonetheless, look what happens to 'another value':

Input:

x = {
    1: [
        a_long_function_of(a_long_variable_name)
        for a_long_variable_name in range(10)
    ],
    2: 'another value'
}

output:

x = {
    1: [
        a_long_function_of(a_long_variable_name)
        for a_long_variable_name in range(10)
    ],
    2: 
    'another value'
}

Config:

[style]
based_on_style = google
split_before_first_argument = True
split_before_logical_operator = True
spaces_around_power_operator = True

[mooskagh]

Fyi as a temporary solution I could work around it by putting values into parentheses. That way it doesn't put them onto a separate line for some reason:

{
   2: ('another value')
}

[gwelymernans]

Opinions on what would be a good heuristic for this? I can think of one:

If a list, dictionary, set, etc. has its opening bracket on the same line as the key, then we don't count it as going over the column limit, even if there's a split after the opening bracket.

Thoughts?

[gabrys]

I think all you need to do is flip INDENT_DICTIONARY_VALUE. Please see PR #483

[r00tat]

This is still present on yapf 0.20.0. Any update on this?

[gabrys]

@r00tat please consider setting indent_dictionary_value = True in your .style.yapf as a workaround (this does have some side effects, so please check if you like it).

The next version of yapf will have this tweak enabled in facebook style.

[r00tat]

For a simple dict it works:

settings = {
    "project_id": "my-project",
    "auth_scopes": ['email'],
    "debug": True,
    "platform": "GAE",
    "force_datastore": False,
}

If I add a function call this breaks the formatting:

settings = {
    "project_id":
    "my-project",
    "auth_scopes": ['email'],
    "debug":
    bool(
        os.environ.get('DEBUG', True if 'Development' in os.environ.get(
            'SERVER_SOFTWARE', '') else False)),
    "platform":
    "GAE",
    "force_datastore":
    False,
}

I would expect it to look like this:

settings = {
    "project_id": "my-project",
    "auth_scopes": ['email'],
    "debug": bool(
        os.environ.get('DEBUG', True if 'Development' in os.environ.get(
            'SERVER_SOFTWARE', '') else False)),
    "platform": "GAE",
    "force_datastore": False,
}

If I add brackets around the values the formatting is correct:

settings = {
    "project_id": ("my-project"),
    "auth_scopes": ['email'],
    "debug":
    bool(
        os.environ.get('DEBUG', True if 'Development' in os.environ.get(
            'SERVER_SOFTWARE', '') else False)),
    "platform": ("GAE"),
    "force_datastore": (False),
}

my yapf config looks like this:

based_on_style = google
column_limit = 99
indent_dictionary_value=true

So still like retr0h described it, when he opened this issue.

[gabrys]

@r00tat Your config seems not applied:

$ sudo pip install yapf
Collecting yapf
  Downloading yapf-0.20.0-py2.py3-none-any.whl (158kB)
    100% |████████████████████████████████| 163kB 1.1MB/s 
Installing collected packages: yapf
Successfully installed yapf-0.20.0
You are using pip version 8.1.1, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
$ mkdir test-yapf
$ cd test-yapf/
$ cat > test.py

settings = {
    "project_id": "my-project",
    "auth_scopes": ['email'],
    "debug": bool(
        os.environ.get('DEBUG', True if 'Development' in os.environ.get(
            'SERVER_SOFTWARE', '') else False)),
    "platform": "GAE",
    "force_datastore": False,
}

$ cat > .style.yapf
[style]
based_on_style = google
column_limit = 99
indent_dictionary_value=true
$ yapf test.py 
settings = {
    "project_id":
        "my-project",
    "auth_scopes": ['email'],
    "debug":
        bool(
            os.environ.get('DEBUG', True
                           if 'Development' in os.environ.get('SERVER_SOFTWARE', '') else False)),
    "platform":
        "GAE",
    "force_datastore":
        False,
}

Maybe you missed the [style] header or something?

To be honest the format is not perfect because it still splits short key-value pairs to multiple lines if there's even one long key-value pair, but at least with the indent it's more or less readable.

[r00tat]

You're right, the style was not applied. I did put the config in setup.cfg which should work according to yapf --help:

  --style STYLE         specify formatting style: either a style name (for
                        example "pep8" or "google"), or the name of a file
                        with style settings. The default is pep8 unless a
                        .style.yapf or setup.cfg file located in the same
                        directory as the source or one of its parent
                        directories (for stdin, the current directory is
                        used).

That's my setup.cfg:

[style]
based_on_style = google
column_limit = 99
indent_dictionary_value=true

[flake8]
max-line-length = 99

If I put the config in .style.yapf the code is formatted as you outlined.

Should I open a new issue for that or am I missing something?

[gabrys]

@r00tat I did the same as you and it looks the style is not applied. This is definitely a separate issue, so I suggest raising another issue. I would suggest using a minimal configuration triggering an error:

.style.yapf:

[style]
indent_dictionary_value=true

test.py:

a = {
    "a": "aaaaaaaaaaaaa",
    "b": "bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb  bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb",
}

$ yapf test.py
settings = {
    "a":
        "aaaaaaaaaaaaa",
    "b":
        "bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb  bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb",
}

Now moving .style.yapf to setup.cfg:

$ mv .style.yapf setup.cfg
$ yapf test.py
settings = {
    "a":
    "aaaaaaaaaaaaa",
    "b":
    "bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb  bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb bbbbbbbbbbbbb",
}

Lines "aaaaaaaaaaaaa", and "bbbbbbbbbbbbb..." are not indented.

[gongzhitaao]

@r00tat I use

based_on_style = facebook
INDENT_DICTIONARY_VALUE=True
ALLOW_SPLIT_BEFORE_DICT_VALUE=False

And it seems to give you the desired formatting.