Требует ли PEP 8 пробелов вокруг операторов в аргументах функции?
У меня есть этот код:
some_list = range(a, b+1)
После проверки моего стиля кодирования с плагином pep8 для vim, я получил это предупреждение:
missing whitespace around operator
Кажется, что, чтобы соответствовать PEP 8, я должен написать это?
some_list = range(a, b + 1)
Но я несколько раз читал PEP 8 - Руководство по стилю для кода Python и просто не могу найти правило, применяемое к предупреждению выше.
Итак, я хочу знать: при использовании стиля PEP-8 требуется пустое пространство вокруг операторов (+, -, *,/и т.д.) в аргументах функции?
Ответы
Ответ 1
http://www.python.org/dev/peps/pep-0008/#other-recommendations
Всегда окружать эти двоичные операторы одним пространством с обеих сторон: присваивание (=), расширенное назначение (+ =, - = и т.д.), сравнения (==, <, > ,! =, < > , < =, > =, in, а не in, is, is not), Booleans (и, или, not).
Исключением является то, что =
используется для установки именованных параметров.
Edit:
Я просмотрел исходный код стандартной библиотеки Python и обнаружил возникновение сценария, представленного выше:
http://hg.python.org/cpython/file/9ddc63c039ba/Lib/json/decoder.py#l203
end = _w(s, end + 1).end()
Ответ 2
Ваш плагин Vim был неправильным, когда вы спросили в 2013 году... но прямо в 2010 году, когда он был автором. PEP 8 несколько раз менял , и ответ на ваш вопрос также изменился.
Первоначально PEP 8 содержал фразу:
Используйте пробелы вокруг арифметических операторов
В соответствии с этим правилом
range(a, b+1)
однозначно ошибочна и должна быть записана как
range(a, b + 1)
Это правило, что pycodestyle (литер-интерфейс Python, ранее известный как pep8.py, опрашивающий Плагин Vim используется под капотом), реализованный в течение нескольких лет.
Тем не менее, это было изменено в апреле 2012 года. Прямой язык, который не оставлял места для усмотрения, был заменен этим советом гораздо глубже:
Если используются операторы с разными приоритетами, попробуйте добавить пробелы вокруг операторов с наименьшим приоритетом (-ами). Используйте свое собственное суждение; однако никогда не используйте более одного пространства и всегда должны иметь одинаковое количество пробелов по обе стороны бинарного оператора.
Смутно, примеры, которые иллюстрируют это правило, изначально остались неизменными (и, следовательно, противоречат прозе). Это было в конечном итоге исправлено, но не очень хорошо, и примеры остаются запутанными, кажущимися более строгими и менее субъективными, чем проза.
До сих пор существует правило, требующее пробелов вокруг некоторых конкретных операторов:
Всегда окружать эти двоичные операторы одним пространством с обеих сторон: назначение (=
), расширенное назначение (+=
, -=
и т.д.), сравнения (==
, <
, >
, !=
, <>
, <=
, >=
, in
, not in
, is
, is not
), Booleans (and
, or
, not
).
но обратите внимание, что это правило явно указывает, к каким операторам он относится, и арифметические операторы, такие как +
, не входят в список.
Таким образом, PEP в его текущей форме не диктует, следует ли использовать пробелы вокруг оператора +
(или других арифметических операторов, таких как *
и /
и **
). Вы можете "использовать свое собственное мнение".
Кстати, pycodestyle linter изменил свое поведение в конце 2012 года, чтобы отразить изменение в PEP, отделяя правила об использовании пробелов вокруг операторов в два кода ошибки, E225 (для того, чтобы не использовать пробелы вокруг операторов, для которых PEP 8 по-прежнему требует пробела), который включен по умолчанию, и E226 (для отказа от использования пробела вокруг арифметических операторов), который по умолчанию игнорируется. Вопрос, задаваемый здесь, должен был использовать слегка устаревшую версию linter, когда он задал этот вопрос в 2013 году, учитывая ошибку, которую он видел.
Ответ 3
Для арифметических операторов я обычно ставлю пробелы вокруг + и -, но не в *, ** и /. Вот пример:
(...)
alpha__w = (wave__w - central_w_par*doppler_factor)/sig_par
e1__w = np.exp(-.5*(alpha__w**2))
Y1__w = norm*e1__w/(sig_par*(2*np.pi)**.5)
(...)