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


103

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.

Risposte:


72

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.


6
questo potrebbe essere il caso, ma sembra ancora strano introdurre questa istanza di icone IMO nei consigli sullo stile del codice per un linguaggio così ben progettato, solo per salvare 2 caratteri. È come se lo stile del codice java dicesse che è meglio inserire {una nuova riga dopo if(salva lo stesso numero di caratteri) ma non nella definizione della classe. Inoltre, un parametro della parola chiave è diverso dal valore predefinito ma utilizza comunque lo stesso consiglio di stile.
soulcheck

3
Come ho detto, sono cose diverse. Ha senso scriverli in modo diverso.
Fortran

6
direi che non è davvero più leggibile di kw1 = kw1, kw2 = kw2;) ma forse era quello che pensavano Guido e Barry.
soulcheck

1
accetterò questa risposta perché è abbastanza convincente. non mi dispiacerebbe un collegamento che lo confermi però
soulcheck

5
Il fatto che l'argomento della parola chiave sia fondamentalmente diverso dall'assegnazione di variabili non è un argomento valido per avere convenzioni diverse IMO, perché la differenza è già chiara dal contesto. Il primo si verifica all'interno di una chiamata di funzione e il secondo deve essere isolato al livello di rientro corrente. IMO, per nomi di variabili più lunghi di 5-6 caratteri (cioè la vita reale per la maggior parte), la variante con spazi è senza dubbio più leggibile.
Axel

13

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 _...


1
quelli sono argomenti di parole chiave, un esempio simile è in PEP, l'ho solo reso meno leggibile
soulcheck

3
Stai dicendo (essenzialmente): per rendere sensata la regola dello spazio vuoto, scrivi nomi di variabili molto brevi. Ma SE si hanno nomi di variabili lunghi, la regola dello spazio vuoto crea un ambiente disordinato. L'argomento che "non è un compito, quindi sono cose diverse" non lo taglia per me, perché ci tengo più alla leggibilità che alla semantica e perché se non è un "valore predefinito per un compito", allora cos'è vero?
PatrickT

1
@PatrickT L'argomento "non è un compito, quindi sono cose diverse" non spiega perché sia (una nozione filosofica); Spiega semplicemente perché può essere (una nozione sintattica).
Mateen Ulhaq

11

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 .


Bene, se aderisci a mettere spazi intorno a =, la ricerca utilizzando gli strumenti non dovrebbe essere diversa.
NoName

10

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


In genere mi piacciono gli spazi, così tanto che tendo a mettere gli spazi anche solo all'interno delle parentesi così tutti i parametri sono circondati dallo spazio. Ma penso che arg1=40sia più leggibile poiché la relazione è più ovvia.
Charlie Gorichanaz

3

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.

3

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.