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.
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.
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_...
IMO leaving out the spaces for args provides cleaner visual grouping of the arg/value pairs; it looks less cluttered.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With