PEP 8, why no spaces around '=' in keyword argument or a default parameter value?

Question

Why does PEP 8 recommend not having spaces around = in a keyword argument or a default parameter value?

Is this inconsistent with recommending spaces around every other

Answer 1

IMO leaving out the spaces for args provides cleaner visual grouping of the arg/value pairs; it looks less cluttered.

Answer 2

There are pros and cons.

I very much dislike how PEP8 compliant code reads. I don't buy into the argument that very_long_variable_name=another_very_long_variable_name can ever be more human readable than very_long_variable_name = another_very_long_variable_name. This is not how people read. It's an additional cognitive load, particularly in the absence of syntax highlighting.

There is a significant benefit, however. If the spacing rules are adhered to, it makes searching for parameters exclusively using tools much more effective.

Answer 3

I think there are several reasons for this, although I might just be rationalizing:

1. It saves space, allowing more function definitions and calls to fit on one line and saving more space for the argument names themselves.
2. By joining each keyword and value, you can more easily separate the different arguments by the space after the comma. This means you can quickly eyeball how many arguments you've supplied.
3. The syntax is then distinct from variable assignments, which may have the same name.
4. Additionally, the syntax is (even more) distinct from equality checks a == b which can also be valid expressions inside a call.

Answer 4

I wouldn't use very_long_variable_name as a default argument. So consider this:

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

over this:

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

Also, it doesn't make much sense to use variables as default values. Perhaps some constant variables (which aren't really constants) and in that case I would use names that are all caps, descriptive yet short as possible. So no another_very_...

Answer 5

I guess that it is because a keyword argument is essentially different than a variable assignment.

For example, there is plenty of code like this:

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

As you see, it makes complete sense to assign a variable to a keyword argument named exactly the same, so it improves readability to see them without spaces. It is easier to recognize that we are using keyword arguments and not assigning a variable to itself.

Also, parameters tend to go in the same line whereas assignments usually are each one in their own line, so saving space is likely to be an important matter there.

Answer 6

For me it makes code more readable and is thus a good convention.

I think the key difference in terms of style between variable assignments and function keyword assignments is that there should only be a single = on a line for the former, whereas generally there are multiple =s on a line for the latter.

If there were no other considerations, we would prefer foo = 42 to foo=42, because the latter is not how equals signs are typically formatted, and because the former nicely visually separates the variable and value with whitespace.

But when there are multiple assignments on one line, we prefer f(foo=42, bar=43, baz=44) to f(foo = 42, bar = 43, baz = 44), because the former visually separates the several assignments with whitespace, whereas the latter does not, making it a bit harder to see where the keyword/value pairs are.

Here's another way of putting it: there is a consistency behind the convention. That consistency is this: the "highest level of separation" is made visually clearer via spaces. Any lower levels of separation are not (because it would be confused with the whitespace separating the higher level). For variable assignment, the highest level of separation is between variable and value. For function keyword assignment, the highest level of separation is between the individual assignments themselves.