Почему объект pylint указывает на имена имен одиночных символов?

Я все еще привык к соглашениям на python и использую pylint чтобы сделать мой код более питоническим, но я озадачен тем фактом, что pylint не любит имена одиночных символов. У меня есть несколько циклов вроде этого:

 for x in x_values: my_list.append(x)

и когда я запускаю pylint , я получаю Invalid name "x" for type variable (should match [a-z_][a-z0-9_]{2,30} что предполагает, что допустимое имя переменной должно быть между 3 и 31 символа, но я просмотрел соглашения об именах PEP8, и я ничего не вижу в отношении отдельных строчных букв, и я вижу много примеров, которые их используют.

Есть ли что-то, что мне не хватает в PEP8, или это стандарт, уникальный для pylint?

4 Solutions collect form web for “Почему объект pylint указывает на имена имен одиночных символов?”

PyLint проверяет не только рекомендации PEP8. Он также имеет свои собственные рекомендации, одним из которых является то, что имя переменной должно быть описательным и не слишком коротким.

Вы можете использовать это, чтобы избежать таких коротких имен:

 my_list.extend(x_values)

Или используйте _ в качестве заполнителя для временных переменных (которые будет проходить регулярное выражение)

Немного больше о том, что заметил gurney alex: вы можете сказать PyLint сделать исключения для имен переменных, которые (вы мизинец клянетесь) совершенно ясны, хотя и меньше трех символов. Найдите или добавьте файл pylint.rc :

 # Good variable names which should always be accepted, separated by a comma good-names=i,j,k,ex,Run,_,pk,x,y

Здесь pk (для первичного ключа), x и y – имена переменных, которые я добавил.

В сильно типизированных языках переменные имени 1 буквы могут быть ok-ish, потому что вы обычно получаете тип рядом с именем в объявлении переменной или в прототипе функции / метода:

 bool check_modality(string a, Mode b, OptionList c) { ModalityChecker v = build_checker(a, b); return v.check_option(c); }

В Python вы не получите эту информацию, поэтому, если вы пишете:

 def check_modality(a, b, c): v = build_checker(a, b) return v.check_option(c)

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

 def check_modality(name, mode, option_list): checker = build_checker(name, mode) return checker.check_option(option_list)

и вы даже добавляете docstring, объясняя, что делает материал и какие типы ожидаются.

Более глубокая причина заключается в том, что вы можете помнить, что вы намеревались использовать a , b , c , x , y и z для обозначения кода, но когда другие читают его или даже когда вы вернетесь к своему коду, код становится гораздо более читаемым, когда вы даете ему семантическое имя. Мы не пишем материал на доске, а затем стираем его. Мы пишем код, который может придерживаться в течение десятилетия или более, и читаться много, много раз.

Используйте семантические имена. Семантические имена, которые я использовал, были похожими на ratio , denominator , obj_generator , path и т. Д. Может потребоваться дополнительная секунда или две, чтобы напечатать их, но время, которое вы сохраняете, пытается выяснить, что вы написали даже через полчаса это того стоит.