È Pythonic usare la comprensione delle liste solo per gli effetti collaterali?

Pensa a una funzione che sto chiamando per i suoi effetti collaterali, non restituire valori (come la stampa sullo schermo, l'aggiornamento della GUI, la stampa su un file, ecc.).

def fun_with_side_effects(x):
    ...side effects...
    return y

Ora, è Pythonic usare le liste di comprensione per chiamare questa funzione:

[fun_with_side_effects(x) for x in y if (...conditions...)]

Nota che non salvo l'elenco da nessuna parte

O dovrei chiamare questa funzione in questo modo:

for x in y:
    if (...conditions...):
        fun_with_side_effects(x)

Quale è meglio e perché?

È molto anti-pitonico farlo, e qualsiasi Pythonista esperto ti darà l'inferno. L'elenco intermedio viene gettato via dopo essere stato creato e potrebbe essere potenzialmente molto, molto grande e quindi costoso da creare.

Non dovresti usare una lista di comprensione, perché come hanno detto le persone, questo creerà un grande elenco temporaneo che non ti serve. I due metodi seguenti sono equivalenti:

consume(side_effects(x) for x in xs)

for x in xs:
    side_effects(x)

con la definizione di consumedalla itertoolspagina man:

def consume(iterator, n=None):
    "Advance the iterator n-steps ahead. If n is none, consume entirely."
    # Use functions that consume iterators at C speed.
    if n is None:
        # feed the entire iterator into a zero-length deque
        collections.deque(iterator, maxlen=0)
    else:
        # advance to the empty slice starting at position n
        next(islice(iterator, n, n), None)

Naturalmente, quest'ultimo è più chiaro e più facile da capire.

Le comprensioni degli elenchi servono per creare elenchi. E a meno che non si sta effettivamente creando una lista, è necessario non utilizzare list comprehension.

Quindi avrei scelto la seconda opzione, semplicemente iterando l'elenco e quindi chiamare la funzione quando si applicano le condizioni.

Il secondo è meglio.

Pensa alla persona che avrebbe bisogno di capire il tuo codice. Puoi ottenere un cattivo karma facilmente con il primo :)

Puoi andare a metà tra i due usando filter (). Considera l'esempio:

y=[1,2,3,4,5,6]
def func(x):
    print "call with %r"%x

for x in filter(lambda x: x>3, y):
    func(x)

Dipende dal tuo obiettivo.

Se stai cercando di eseguire alcune operazioni su ogni oggetto in un elenco, è necessario adottare il secondo approccio.

Se stai cercando di generare un elenco da un altro elenco, puoi utilizzare la comprensione dell'elenco.

Esplicito è meglio che implicito. Semplice è meglio che complesso. (Python Zen)

Tu puoi fare

for z in (fun_with_side_effects(x) for x in y if (...conditions...)): pass

ma non è molto carino.

Usare una comprensione delle liste per i suoi effetti collaterali è brutto, non pitonico, inefficiente e non lo farei. Io forinvece userei un loop, perché un forloop segnala uno stile procedurale in cui gli effetti collaterali sono importanti.

Ma, se insisti assolutamente nell'usare una comprensione dell'elenco per i suoi effetti collaterali, dovresti evitare l'inefficienza usando invece un'espressione generatrice. Se insisti assolutamente su questo stile, esegui uno di questi due:

any(fun_with_side_effects(x) and False for x in y if (...conditions...))

o:

all(fun_with_side_effects(x) or True for x in y if (...conditions...))

Queste sono espressioni del generatore e non generano un elenco casuale che viene buttato fuori. Penso che il allmodulo sia forse leggermente più chiaro, anche se penso che entrambi siano confusi e non dovrebbero essere usati.

Penso che questo sia brutto e in realtà non lo farei in codice. Ma se insisti a implementare i tuoi loop in questo modo, è così che lo farei.

Tendo a ritenere che le comprensioni degli elenchi e il loro genere dovrebbero segnalare un tentativo di utilizzare qualcosa che assomigli almeno vagamente a uno stile funzionale. Mettere cose con effetti collaterali che infrangono questo presupposto farà sì che le persone debbano leggere il tuo codice più attentamente, e penso che sia una brutta cosa.