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 будут оценены.

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

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

Ответ 1

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

Например, есть много таких кодов:

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

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

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

Ответ 2

Я бы не использовал 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')

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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