2010-01-13 8 views
103

Come andresti sulla formattazione di una lunga fila come questa? Mi piacerebbe arrivare a non più di 80 caratteri:Come posso suddividere questa lunga linea in Python?

logger.info("Skipping {0} because its thumbnail was already in our system as {1}.".format(line[indexes['url']], video.title)) 

Questa è la mia migliore opzione?

url = "Skipping {0} because its thumbnail was already in our system as {1}." 
logger.info(url.format(line[indexes['url']], video.title)) 
+1

Sembra una buona opzione. Cosa non ti piace a riguardo? –

+2

Un po 'soggettivo, non è vero? :) –

+1

correlati: http://stackoverflow.com/questions/1940710/syntax-quirks-or-why-is-that-valid-python (concatenazione di stringhe in python) – jldupont

risposta

213

Questo è un inizio. Non è una cattiva pratica definire le stringhe più lunghe al di fuori del codice che le utilizza. È un modo per separare dati e comportamenti. La prima opzione è quella di unire le stringhe letterali insieme implicitamente facendoli adiacenti l'uno all'altro:

("This is the first line of my text, " 
"which will be joined to a second.") 

O con linea termina continuazioni, che è un po 'più fragile, come questo funziona:

"This is the first line of my text, " \ 
"which will be joined to a second." 

Ma questo non lo fa:

"This is the first line of my text, " \ 
"which will be joined to a second." 

Vedi la differenza? No? Beh, non lo farai nemmeno quando è il tuo codice.

L'aspetto negativo di unione implicita è che funziona solo con le stringhe, non con le stringhe prese da variabili, quindi le cose possono ottenere un po 'più peloso quando si refactoring. Inoltre, puoi solo interpolare la formattazione sulla stringa combinata nel suo complesso.

In alternativa, è possibile partecipare in modo esplicito utilizzando l'operatore di concatenazione (+):

("This is the first line of my text, " + 
"which will be joined to a second.") 

Esplicito è meglio che implicita, come lo Zen di pitone, dice, ma questo crea tre corde invece di uno, e utilizza due volte tanta memoria: ci sono i due che hai scritto, più uno che è loro due uniti, quindi devi sapere quando ignorare lo zen. Il lato positivo è che è possibile applicare la formattazione a una qualsiasi delle sottostringhe separatamente su ogni riga o all'intero lotto al di fuori delle parentesi.

Infine, è possibile utilizzare le stringhe triple-citato:

"""This is the first line of my text 
which will be joined to a second.""" 

Questo è spesso il mio preferito, anche se il suo comportamento è leggermente diversa in quanto il ritorno a capo e un qualsiasi spazio su righe successive verranno visualizzati nella stringa finale . È possibile eliminare la nuova riga con una barra rovesciata di escape.

"""This is the first line of my text \ 
which will be joined to a second.""" 

Questo ha lo stesso problema come la stessa tecnica sopra, dal fatto che il codice corretto differisce dal codice non corretto da spazi bianchi invisibile.

Quale è "il migliore" dipende dalla situazione particolare, ma la risposta non è semplicemente estetica, ma uno di comportamenti leggermente diversi.

+15

Il compilatore CPython ottimizza il più possibile le operazioni letterali, il che significa che l'aggiunta di due valori letterali stringa restituisce solo un singolo valore letterale stringa nel bytecode. –

+1

Mentre tutte le risposte che ho ricevuto sono utili, la tua sicuramente mi aiuta a capire tutti i modi per rompere le stringhe. Era il problema con la riga "\" che terminava che c'era uno spazio dopo di esso? – Gattster

+0

Non riesco a vedere la differenza qui, ma poi, questo è principalmente dovuto alla colorazione sintattica piuttosto primitiva di SO. (Un codice perfettamente buono è praticamente illeggibile su SO, ma solo perché non è in una lingua la cui sintassi è molto vicina a C.) Non è raro che il tuo editor evidenzi in modo odioso gli spazi finali, poiché sono raramente utili (o intenzionali) . :-) – Ken

27

consecutivi stringhe letterali sono uniti dal compilatore, e tra parentesi le espressioni sono considerati come una singola riga di codice:

logger.info("Skipping {0} because it's thumbnail was " 
    "already in our system as {1}.".format(line[indexes['url']], 
    video.title)) 
7

Personalmente non mi piace appendere blocchi aperti, quindi mi piacerebbe formattarla come :

logger.info(
    'Skipping {0} because its thumbnail was already in our system as {1}.' 
    .format(line[indexes['url']], video.title) 
) 

In generale non mi preoccuperei troppo difficile lottare per rendere il codice in forma esattamente all'interno di una linea di 80 colonne. Vale la pena mantenere la lunghezza della linea a livelli ragionevoli, ma il limite di 80 hard è una cosa del passato.

+6

Non è davvero una cosa del passato. La libreria standard Python utilizza ancora PEP8 come guida allo stile, quindi la regola esiste ancora e molte persone (me compreso) la seguono. È un posto comodo per tracciare la linea. –

+2

Mi chiedo quanti progetti seguano ancora la regola 80 caratteri. Per la dimensione media della finestra che utilizzo, penso che 100-120 sia più produttivo per me di 80 caratteri. – Gattster

+1

Sì, si tratta della lunghezza della linea che uso anch'io, anche se [horror! sacrilegio!] Uso un font proporzionale, quindi la lunghezza della linea esatta non è così critica. È più un caso di quanto logica su una singola riga sia leggibile di quanti caratteri, in quanto tale ... se ho una lunga serie di dati che nessuno ha bisogno di leggere sono felice di lasciarlo traboccare 120. – bobince

Problemi correlati