Почему объект 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?

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 и т. Д. Может потребоваться дополнительная секунда или две, чтобы напечатать их, но время, которое вы сохраняете, пытается выяснить, что вы написали даже через полчаса это того стоит.