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 occurrence of = in Python code?

How is:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

better than:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Any links to discussion/explanation by Python's BDFL will be appreciated.

Mind, this question is more about kwargs than default values, i just used the phrasing from PEP 8.

I'm not soliciting opinions. I'm asking for reasons behind this decision. It's more like asking why would I use { on the same line as if statement in a C program, not whether I should use it or not.

Answer 1

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 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 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 4

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

Answer 5

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.

Answer 6

I personally feel that a single space before and after ALL assignment operators = should be standard regardless of the programming/markup language, because it helps the eye differentiate between tokens of different channels (i.e. isolating a variable/parameter name token, from an assignment operator token =, from a value token/sequence of expression value tokens).

It is neither readable nor intuitive to clump three tokens of three different channels into a single "parameter-name-assignment-operator-value/expression-tuple" token.

For example, let's consider non-delimited tokens:

def my_func(par1: str, par2: str):
    print('%s %s' % (par1, par2))

cond = 'conditional string'
my_func(par1='string with a lot of spaces',
        par2=cond if cond is not None else 'no string')

Granted, the value passed to par2 should probably be stored into a variable rather than passed as a "ternary" expression...

par2 = cond if cond is not None else 'no string'
my_func(par1='string with a lot of spaces', 
        par2=par2)

...but should we decide to use the ternary expression anyways, I find that adding the delimiting spaces before and after the assignment operators to be more readable, almost like a dictionary object (which python parameter sequences basically are):

my_func(par1 = 'string with a lot of spaces', 
        par2 = cond if cond is not None else 'no string')
# OR
par2 = cond if cond is not None else 'no string'
my_func(par1 = 'string with a lot of spaces', 
        par2 = par2)

Answer 7

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.