¿Por qué pylint se opone a los nombres de variables de un solo carácter?

Todavía me estoy acostumbrando a las convenciones de Python y las uso pylintpara hacer mi código más pitónico, pero estoy desconcertado por el hecho de que a pylint no le gustan los nombres de variables de un solo carácter. Tengo algunos bucles como este:

for x in x_values:
   my_list.append(x)

y cuando ejecuto pylint, obtengo Invalid name "x" for type variable (should match [a-z_][a-z0-9_]{2,30}, eso sugiere que un nombre de variable válido debe tener entre 3 y 31 caracteres de longitud, pero he revisado las convenciones de nomenclatura de PEP8 y no veo nada explícito con respecto a letras minúsculas individuales , y veo muchos ejemplos que los usan.

¿Hay algo que me falta en PEP8 o es un estándar exclusivo de pylint?

PyLint comprueba no solo las recomendaciones de PEP8. También tiene sus propias recomendaciones, una de las cuales es que el nombre de una variable debe ser descriptivo y no demasiado corto.

Puede usar esto para evitar nombres tan cortos:

my_list.extend(x_values)

O modifique la configuración de PyLint para decirle a PyLint qué nombre de variable es bueno.

Un poco más de detalle sobre lo que gurney alex notó: puede decirle a PyLint que haga excepciones para los nombres de variables que (juro con el dedo meñique) son perfectamente claros aunque tengan menos de tres caracteres. Busque o agregue a su archivo pylintrc , debajo del [FORMAT]encabezado:

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

Aquí pk (para clave principal), xey son nombres de variables que he agregado.

En lenguajes fuertemente tipados, las variables de nombre de 1 letra pueden estar bien, porque generalmente obtienes el tipo junto al nombre en la declaración de la variable o en el prototipo de función / método:

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

En Python, no obtienes esta información, así que si escribes:

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

no le está dejando absolutamente ninguna pista al equipo de mantenimiento sobre lo que podría estar haciendo la función, cómo se llama y qué devuelve. Entonces, en Python, tiende a usar nombres descriptivos:

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

e incluso agrega una cadena de documentos que explica qué hacen las cosas y qué tipos se esperan.

Hoy en día también existe una opción para anular regexp. Es decir, si desea permitir caracteres individuales como variables:

pylint --variable-rgx="[a-z0-9_]{1,30}$" <filename>

Por lo tanto, pylintcoincidirá con PEP8 y no traerá violaciones adicionales en la parte superior. También puedes agregarlo a .pylintrc.

La razón más profunda es que usted puede recordar lo que pretende a, b, c, x, y, y zpara decir cuando escribió su código, pero cuando otros leen, o incluso cuando regresan a su código, el código se vuelve mucho más fácil de leer cuando das es un nombre semántico. No escribimos cosas una vez en una pizarra y luego las borramos. Estamos escribiendo un código que podría durar una década o más y que se leerá muchas, muchas veces.

Utilice nombres semánticos. Nombres semánticas que he usado han sido como ratio, denominator, obj_generator, path, etc. Se puede tomar un segundo extra o dos para escribir a cabo, pero el tiempo que se ahorra tratando de averiguar lo que ha escrito ni media hora a partir de entonces es bien vale la pena .