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


104

Почему 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, не является ли я должен использовать его или нет.

Ответы:


73

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

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

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

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

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


7
это могло быть так, но все же кажется странным вводить эту согласованность значков IMO в рекомендации по стилю кода для такого хорошо разработанного языка, только чтобы сохранить 2 символа. Это как если бы стиль кода java сказал, что {после if(сохраняет такое же количество символов), но не в определении класса , петтер ставить новую строку . Также параметр ключевого слова отличается от значения по умолчанию, но по-прежнему использует ту же рекомендацию стиля.
soulcheck

3
Как я уже сказал, это разные вещи. Имеет смысл написать их по-другому.
fortran

6
Я бы сказал, что это не более читабельно, чем kw1 = kw1, kw2 = kw2;) но, возможно, именно так думали Гвидо и Барри.
soulcheck

1
Я приму этот ответ, поскольку он довольно убедителен. хотя бы ссылку, подтверждающую это,
soulcheck

5
Тот факт, что аргумент ключевого слова принципиально отличается от присвоения переменной, не является допустимым аргументом для разных соглашений IMO, потому что разница уже очевидна из контекста. Первое происходит внутри вызова функции, а второе должно стоять отдельно на текущем уровне отступа. IMO, для имен переменных длиннее 5-6 символов (т.е. для большинства из них в реальной жизни) вариант с пробелами более читабелен.
Axel

13

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

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


1
это аргументы ключевых слов, аналогичный пример есть в PEP, я только сделал его менее читаемым
soulcheck

3
Вы говорите (по сути): чтобы сделать правило без пробелов разумным, пишите очень короткие имена переменных. Но ЕСЛИ у кого-то длинные имена переменных, то правило отсутствия пробелов создает загроможденную среду. Аргумент, что «это не присвоение, значит, это разные вещи» меня не устраивает, потому что меня больше волнует удобочитаемость, чем семантика, и потому что, если это не «значение по умолчанию для присвоения», то что Это?
PatrickT

1
@PatrickT Аргумент «это не задание, значит, это разные вещи» никак не объясняет, почему это так (философское понятие); Это просто объясняет, почему это может быть (синтаксическое понятие).
Матин Улхак

11

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

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

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


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

10

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


Мне вообще нравятся пробелы, поэтому я стараюсь помещать пробелы внутри скобок, чтобы все параметры были окружены пробелами. Но я думаю, что arg1=40это более читабельно, поскольку взаимосвязь более очевидна.
Чарли Горичаназ

3

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

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

3

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.