Perché pylint si oppone ai nomi di variabili a carattere singolo?

Mi sto ancora abituando alle convenzioni di Python e lo uso pylintper rendere il mio codice più pitonico, ma sono perplesso dal fatto che a pylint non piacciano i nomi delle variabili a carattere singolo. Ho alcuni loop come questo:

for x in x_values:
   my_list.append(x)

e quando eseguo pylint, ottengo Invalid name "x" for type variable (should match [a-z_][a-z0-9_]{2,30}- questo suggerisce che un nome di variabile valido deve essere lungo tra 3 e 31 caratteri, ma ho esaminato le convenzioni di denominazione PEP8 e non vedo nulla di esplicito riguardo alle singole lettere minuscole e vedo molti esempi che li usano.

C'è qualcosa che mi manca in PEP8 o è uno standard unico per pylint?

PyLint controlla non solo le raccomandazioni PEP8. Ha anche le sue raccomandazioni, una delle quali è che il nome di una variabile dovrebbe essere descrittivo e non troppo breve.

Puoi usarlo per evitare nomi così brevi:

my_list.extend(x_values)

Oppure modifica la configurazione di PyLint per dire a PyLint quale nome di variabile è buono.

Un po 'più di dettaglio su ciò che ha notato gurney alex: puoi dire a PyLint di fare eccezioni per i nomi di variabili che (giuri mignolo) sono perfettamente chiari anche se meno di tre caratteri. Trova o aggiungi al tuo file pylintrc , sotto l' [FORMAT]intestazione:

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

Qui pk (per la chiave primaria), x e y sono nomi di variabili che ho aggiunto.

Nei linguaggi fortemente tipizzati, le variabili del nome di 1 lettera possono essere ok, perché generalmente ottieni il tipo accanto al nome nella dichiarazione della variabile o nel prototipo di funzione / metodo:

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

In Python, non ottieni queste informazioni, quindi se scrivi:

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

non lasci assolutamente alcun indizio al team di manutenzione su cosa potrebbe fare la funzione, come viene chiamata e cosa restituisce. Quindi in Python, tendi a usare nomi descrittivi:

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

e aggiungi anche una docstring che spiega cosa fa il materiale e quali tipi sono previsti.

Al giorno d'oggi c'è anche un'opzione per sovrascrivere regexp. Ad esempio, se vuoi consentire singoli caratteri come variabili:

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

Quindi, pylintcorrisponderà a PEP8 e non porterà ulteriori violazioni in cima. Inoltre puoi aggiungerlo a .pylintrc.

La ragione più profonda è che si può ricordare quello che intendeva a, b, c, x, y, e zper dire quando hai scritto il codice, ma quando gli altri leggono, o anche quando si torna al codice, il codice diventa molto più leggibile quando si danno è un nome semantico. Non stiamo scrivendo roba una volta su una lavagna e poi cancellandola. Stiamo scrivendo codice che potrebbe rimanere in vigore per un decennio o più e che verrà letto molte, molte volte.

Usa nomi semantici. Nomi semantiche che ho usato sono stati come ratio, denominator, obj_generator, path, ecc Si può prendere un secondo in più o due per tipo fuori, ma il tempo si salva cercando di capire quello che hai scritto, anche a mezz'ora da allora è valsa la pena .