Por que o pylint se opõe a nomes de variáveis ​​de caractere único?

Ainda estou me acostumando com as convenções do python e usando pylintpara tornar meu código mais python , mas estou confuso pelo fato de que o pylint não gosta de nomes de variáveis ​​com um único caractere. Eu tenho alguns loops como este:

for x in x_values:
   my_list.append(x)

e quando eu corro pylint, estou obtendo Invalid name "x" for type variable (should match [a-z_][a-z0-9_]{2,30}- isso sugere que um nome de variável válido deve ter entre 3 e 31 caracteres, mas eu olhei através das convenções de nomenclatura PEP8 e não vejo nada explícito sobre letras minúsculas simples , e vejo muitos exemplos que os usam.

Há algo que estou perdendo no PEP8 ou este é um padrão exclusivo do pylint?

O PyLint verifica não apenas as recomendações PEP8. Ele também tem suas próprias recomendações, uma das quais é que o nome de uma variável deve ser descritivo e não muito curto.

Você pode usar isso para evitar nomes curtos:

my_list.extend(x_values)

Ou ajuste a configuração do PyLint para informar ao PyLint quais nomes de variáveis ​​são bons.

Um pouco mais de detalhes sobre o que maca alex notou: você pode dizer ao PyLint para fazer exceções para nomes de variáveis que (você jura o dedo mínimo) são perfeitamente claros, embora tenham menos de três caracteres. Encontre ou adicione ao seu arquivo pylintrc , sob o [FORMAT]cabeçalho:

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

Aqui pk (para chave primária), xey são nomes de variáveis ​​que adicionei.

Em linguagens fortemente tipadas, as variáveis ​​de nome de 1 letra podem ser ok-ish, porque geralmente você obtém o tipo próximo ao nome na declaração da variável ou no protótipo de função / método:

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

Em Python, você não obtém essas informações, portanto, se escrever:

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

você não está deixando absolutamente nenhuma pista para a equipe de manutenção sobre o que a função poderia estar fazendo, como é chamada e o que retorna. Portanto, em Python, você tende a usar nomes descritivos:

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

e você até adiciona uma docstring explicando o que as coisas fazem e quais tipos são esperados.

Hoje em dia também existe a opção de substituir o regexp. Ou seja, se você quiser permitir caracteres únicos como variáveis:

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

Portanto, pylintcorresponderá ao PEP8 e não trará violações adicionais no topo. Além disso, você pode adicioná-lo .pylintrc.

A razão mais profunda é que você pode se lembrar o que você pretendia a, b, c, x, y, e zpara dizer quando escreveu seu código, mas quando os outros lê-lo, ou mesmo quando você voltar para o seu código, o código torna-se muito mais legível quando você dá é um nome semântico. Não estamos escrevendo coisas uma vez no quadro-negro e depois apagando. Estamos escrevendo um código que pode durar uma década ou mais e ser lido muitas e muitas vezes.

Use nomes semânticos. Nomes semânticas que usei ter sido como ratio, denominator, obj_generator, path, etc. Pode demorar um segundo extra ou dois para digitá-los para fora, mas o tempo que você salvar tentando descobrir o que você escreveu até meia hora a partir de então vale a pena .