PEP 8, perché nessuno spazio intorno a '=' nell'argomento della parola chiave o un valore di parametro predefinito?

Perché PEP 8 consiglia di non avere spazi =in un argomento di parola chiave o in un valore di parametro predefinito ?

Questo è incoerente con la raccomandazione di spazi attorno a ogni altra occorrenza di =nel codice Python?

Com'è:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

meglio di:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Eventuali collegamenti a discussioni / spiegazioni da BDFL di Python saranno apprezzati.

Mente, questa domanda riguarda più i kwarg che i valori predefiniti, ho appena usato la frase di PEP 8.

Non sto sollecitando opinioni. Chiedo i motivi alla base di questa decisione. È più come chiedere perché dovrei usare {sulla stessa riga ifdell'istruzione in un programma C, non se dovrei usarlo o meno.

Immagino che sia perché l'argomento di una parola chiave è essenzialmente diverso dall'assegnazione di una variabile.

Ad esempio, c'è un sacco di codice come questo:

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

Come vedi, ha perfettamente senso assegnare una variabile a un argomento di parola chiave con lo stesso nome, quindi migliora la leggibilità per vederli senza spazi. È più facile riconoscere che stiamo usando argomenti di parole chiave e non assegniamo una variabile a se stesso.

Inoltre, i parametri tendono ad andare sulla stessa riga, mentre le assegnazioni di solito sono ciascuna nella propria riga, quindi è probabile che risparmiare spazio sia una questione importante.

Non userei very_long_variable_name come argomento predefinito. Quindi considera questo:

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

su questo:

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

Inoltre, non ha molto senso utilizzare le variabili come valori predefiniti. Forse alcune variabili costanti (che non sono realmente costanti) e in quel caso userei nomi che sono tutti maiuscoli, descrittivi ma più brevi possibile. Quindi nessun altro_very _...

Ci sono pro e contro.

Non mi piace molto il modo in cui legge il codice conforme a PEP8. Non mi piace l'argomento che very_long_variable_name=another_very_long_variable_namepotrà mai essere più leggibile dall'uomo di very_long_variable_name = another_very_long_variable_name. Non è così che le persone leggono. È un carico cognitivo aggiuntivo, in particolare in assenza di evidenziazione della sintassi.

Tuttavia, c'è un vantaggio significativo. Il rispetto delle regole di spaziatura rende molto più efficace la ricerca dei parametri utilizzando esclusivamente strumenti .

IMO tralasciando gli spazi per args fornisce un raggruppamento visivo più pulito delle coppie arg / value; sembra meno ingombra.

Penso che ci siano diverse ragioni per questo, anche se potrei semplicemente razionalizzare:

1. Risparmia spazio, consentendo a più definizioni di funzioni e chiamate di adattarsi su una riga e risparmiando più spazio per i nomi degli argomenti stessi.
2. Unendo ogni parola chiave e valore, puoi separare più facilmente i diversi argomenti con lo spazio dopo la virgola. Ciò significa che puoi rapidamente osservare quanti argomenti hai fornito.
3. La sintassi è quindi distinta dalle assegnazioni di variabili, che possono avere lo stesso nome.
4. Inoltre, la sintassi è (ancora di più) distinta dai controlli di uguaglianza a == bche possono anche essere espressioni valide all'interno di una chiamata.

Per me rende il codice più leggibile ed è quindi una buona convenzione.

Penso che la differenza fondamentale in termini di stile tra assegnazioni di variabili e assegnazioni di parole chiave di funzione sia che dovrebbe esserci solo una singola =riga per la prima, mentre generalmente ci sono più =s su una riga per la seconda.

Se non ci fossero altre considerazioni, noi preferiremmo foo = 42a foo=42, perché quest'ultimo non è come segni di uguaglianza sono tipicamente formattati, e perché i primi ben separa visivamente il variabile e il valore con spazi bianchi.

Ma quando ci sono più assegnazioni in un'unica linea, preferiamo f(foo=42, bar=43, baz=44)a f(foo = 42, bar = 43, baz = 44), perché il primo separa visivamente le varie assegnazioni con spazi, mentre la seconda non, rendendo un po 'più difficile da vedere dove le coppie parola / valore sono.

Ecco un altro modo di metterla: non è una consistenza dietro la convenzione. Quella coerenza è questa: il "più alto livello di separazione" è reso visivamente più chiaro tramite gli spazi. Qualsiasi livello inferiore di separazione non lo è (perché verrebbe confuso con lo spazio bianco che separa il livello superiore). Per l'assegnazione di variabili, il livello di separazione più elevato è tra variabile e valore. Per l'assegnazione di parole chiave di funzione, il livello più alto di separazione è tra le singole assegnazioni stesse.