PEP 8, por que não há espaços em torno de '=' no argumento de palavra-chave ou um valor de parâmetro padrão?

Por que o PEP 8 recomenda não ter espaços =em um argumento de palavra-chave ou um valor de parâmetro padrão ?

Isso é inconsistente com a recomendação de espaços em torno de todas as outras ocorrências de =no código Python?

Como é:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

melhor que:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Quaisquer links para discussão / explicação pelo BDFL do Python serão apreciados.

Lembre-se, esta questão é mais sobre kwargs do que valores padrão, eu apenas usei a frase do PEP 8.

Não estou solicitando opiniões. Estou pedindo as razões por trás desta decisão. É mais como perguntar por que eu usaria {na mesma linha que a ifinstrução em um programa C, e não se devo usar ou não.

Acho que é porque um argumento de palavra-chave é essencialmente diferente de uma atribuição de variável.

Por exemplo, há muitos códigos como este:

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

Como você pode ver, faz todo o sentido atribuir uma variável a um argumento de palavra-chave com o mesmo nome, portanto, melhora a legibilidade para vê-los sem espaços. É mais fácil reconhecer que estamos usando argumentos de palavra-chave e não atribuindo uma variável a si mesmo.

Além disso, os parâmetros tendem a ir na mesma linha, enquanto as atribuições geralmente estão cada uma em sua própria linha, portanto, economizar espaço é provavelmente uma questão importante aqui.

Eu não usaria very_long_variable_name como um argumento padrão. Portanto, considere o seguinte:

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

por cima disto:

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

Além disso, não faz muito sentido usar variáveis ​​como valores padrão. Talvez algumas variáveis ​​constantes (que não são realmente constantes) e, nesse caso, eu usaria nomes todos em maiúsculas, descritivos, mas o mais curtos possível. Portanto, nenhum outro_muito _...

Há prós e contras.

Não gosto muito de como o código compatível com PEP8 é lido. Eu não acredito no argumento que very_long_variable_name=another_very_long_variable_namepode ser mais legível por humanos do que very_long_variable_name = another_very_long_variable_name. Não é assim que as pessoas lêem. É uma carga cognitiva adicional, especialmente na ausência de destaque de sintaxe.

Porém, há um benefício significativo. Se as regras de espaçamento forem respeitadas, torna-se muito mais eficaz a busca de parâmetros exclusivamente com ferramentas .

O IMO deixando de fora os espaços para args fornece um agrupamento visual mais limpo dos pares arg / valor; parece menos confuso.

Acho que há várias razões para isso, embora eu possa estar apenas racionalizando:

1. Ele economiza espaço, permitindo que mais definições de função e chamadas caibam em uma linha e economizando mais espaço para os próprios nomes dos argumentos.
2. Ao juntar cada palavra-chave e valor, você pode separar mais facilmente os diferentes argumentos pelo espaço após a vírgula. Isso significa que você pode avaliar rapidamente quantos argumentos forneceu.
3. A sintaxe é então distinta das atribuições de variáveis, que podem ter o mesmo nome.
4. Além disso, a sintaxe é (ainda mais) distinta das verificações de igualdade, a == bque também podem ser expressões válidas dentro de uma chamada.

Para mim, torna o código mais legível e, portanto, é uma boa convenção.

Acho que a principal diferença em termos de estilo entre as atribuições de variáveis ​​e as atribuições de palavras-chave de função é que deve haver apenas um único =em uma linha para as primeiras, enquanto geralmente há vários =s em uma linha para as últimas.

Se não houvesse outras considerações, nós preferimos foo = 42a foo=42, porque o último não é como sinais de igual são tipicamente formatado, e porque o primeiro bem separa visualmente a variável e valor com espaços em branco.

Mas, quando há várias atribuições em uma linha, nós preferimos f(foo=42, bar=43, baz=44)a f(foo = 42, bar = 43, baz = 44), porque o ex-separa visualmente as várias atribuições com espaços em branco, enquanto o segundo não, tornando-se um pouco mais difícil de ver onde os pares de chave / valor são.

Aqui está outra maneira de colocá-lo: não é uma consistência atrás da convenção. Essa consistência é esta: o "nível mais alto de separação" torna-se visualmente mais claro através dos espaços. Qualquer nível inferior de separação não o é (porque seria confundido com o espaço em branco que separa o nível superior). Para atribuição de variável, o nível mais alto de separação é entre variável e valor. Para atribuição de palavra-chave de função, o nível mais alto de separação é entre as próprias atribuições individuais.