PEP 8, почему нет пробелов вокруг '=' в аргументе ключевого слова или значении параметра по умолчанию?

Почему PEP 8 рекомендует не иметь пробелов =в аргументе ключевого слова или значении параметра по умолчанию ?

Это несовместимо с рекомендацией пробелов вокруг каждого другого вхождения =в код Python?

Как:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

лучше чем:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Будем признательны за любые ссылки на обсуждение / объяснение Python BDFL .

Имейте в виду, этот вопрос больше о kwargs, чем о значениях по умолчанию, я просто использовал формулировку из PEP 8.

Я не спрашиваю мнения. Я спрашиваю о причинах этого решения. Это больше походит на выяснение , почему бы использовать {на той же линии , как ifзаявление в программе C, не является ли я должен использовать его или нет.

Я предполагаю, что это потому, что аргумент ключевого слова существенно отличается от присваивания переменной.

Например, такого кода много:

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

Как видите, имеет смысл назначить переменную аргументу ключевого слова с точно таким же именем, чтобы улучшить удобочитаемость, чтобы увидеть их без пробелов. Легче понять, что мы используем аргументы ключевого слова, а не присваиваем себе переменную.

Кроме того, параметры, как правило, помещаются в одну строку, тогда как назначения обычно находятся в отдельной строке, поэтому экономия места, вероятно, будет здесь важным вопросом.

Я бы не стал использовать very_long_variable_name в качестве аргумента по умолчанию. Итак, рассмотрим это:

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

через это:

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

Кроме того, нет особого смысла использовать переменные в качестве значений по умолчанию. Возможно, некоторые постоянные переменные (которые на самом деле не являются константами), и в этом случае я бы использовал имена, которые все заглавные, описательные, но по возможности короткие. Так что нет другого_ очень _...

Есть плюсы и минусы.

Мне очень не нравится, как читается код, совместимый с PEP8. Я не верю аргументу, который very_long_variable_name=another_very_long_variable_nameможет быть более понятным для человека, чем very_long_variable_name = another_very_long_variable_name. Люди не так читают. Это дополнительная когнитивная нагрузка, особенно при отсутствии подсветки синтаксиса.

Однако есть существенное преимущество. При соблюдении правил интервалов поиск параметров исключительно с помощью инструментов становится более эффективным.

ИМО, оставляя пробелы для аргументов, обеспечивает более четкую визуальную группировку пар аргумент / значение; выглядит менее загроможденным.

Я думаю, что этому есть несколько причин, хотя я мог бы просто пояснить:

1. Это экономит место, позволяя помещать больше определений функций и вызовов в одну строку и экономя больше места для самих имен аргументов.
2. Объединив каждое ключевое слово и значение, вы можете легче разделить различные аргументы пробелом после запятой. Это означает, что вы можете быстро увидеть, сколько аргументов вы указали.
3. В этом случае синтаксис отличается от присвоения переменных, которые могут иметь одно и то же имя.
4. Кроме того, синтаксис (даже больше) отличается от проверок равенства, a == bкоторые также могут быть действительными выражениями внутри вызова.

Для меня это делает код более читаемым и, следовательно, является хорошим соглашением.

Я думаю, что ключевое различие в стиле между назначениями переменных и назначениями ключевых слов функций заключается в том, что =для первого в строке должно быть только одно , тогда как обычно есть несколько= для второго в строке s.

Если бы не было никаких других соображений, мы предпочли бы , foo = 42чтобыfoo=42 , потому что последний не так, как знак равенства , как правило , отформатирован, и потому , что бывший хорошо визуально отделяет переменную и значение с пробелами.

Но когда есть несколько заданий на одной строке, мы предпочитаем , f(foo=42, bar=43, baz=44)чтобыf(foo = 42, bar = 43, baz = 44) , потому что первое визуально разделяет несколько назначений пробелами, а второе - нет, что немного затрудняет поиск пар ключевых слов / значений.

Вот еще один способ выразить это: за конвенцией стоит последовательность. Последовательность заключается в следующем: «высший уровень разделения» становится визуально более четким через пробелы. Никаких более низких уровней разделения нет (потому что это можно было бы спутать с пробелом, разделяющим более высокий уровень). Для присвоения переменной самый высокий уровень разделения - между переменной и значением. Для назначения ключевых слов функции самый высокий уровень разделения - между самими отдельными назначениями.