Czy Pythonic używa list składanych tylko do efektów ubocznych?

Pomyśl o funkcji, którą wywołuję ze względu na jej skutki uboczne, a nie zwracanie wartości (jak drukowanie na ekranie, aktualizacja GUI, drukowanie do pliku itp.).

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

Teraz, czy Pythonic ma używać wyrażeń listowych do wywoływania tej funkcji:

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

Zauważ, że nigdzie nie zapisuję listy

A może powinienem nazwać tę funkcję w ten sposób:

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

Który jest lepszy i dlaczego?

Jest to bardzo anty-Pythonic, a każdy doświadczony Pythonista sprawi, że będziesz miał nad tym piekło. Lista pośrednia jest wyrzucana po utworzeniu i potencjalnie może być bardzo, bardzo duża, a zatem kosztowna w tworzeniu.

Nie powinieneś używać rozumienia list , ponieważ, jak powiedzieli ludzie, utworzy to dużą tymczasową listę, której nie potrzebujesz. Następujące dwie metody są równoważne:

consume(side_effects(x) for x in xs)

for x in xs:
    side_effects(x)

z definicją ze consumestrony podręcznika itertools:

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)

Oczywiście to drugie jest jaśniejsze i łatwiejsze do zrozumienia.

Listy składane służą do tworzenia list. I chyba faktycznie tworzenia listy, należy nie używać wyrażeń listowych.

Więc dostałbym drugą opcję, po prostu iterując po liście, a następnie wywołując funkcję, gdy mają zastosowanie warunki.

Druga jest lepsza.

Pomyśl o osobie, która musiałaby zrozumieć Twój kod. Za pierwszym razem możesz łatwo zdobyć złą karmę :)

Możesz przejść między nimi, używając filter (). Rozważmy przykład:

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)

Zależy od twojego celu.

Jeśli próbujesz wykonać jakąś operację na każdym obiekcie z listy, należy zastosować drugie podejście.

Jeśli próbujesz wygenerować listę z innej listy, możesz użyć rozumienia list.

Jawne jest lepsze niż niejawne. Proste jest lepsze niż złożone. (Python Zen)

Możesz to zrobić

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

ale nie jest zbyt ładna.

Używanie funkcji rozumienia list do efektów ubocznych jest brzydkie, nie-Pythoniczne, nieefektywne i nie zrobiłbym tego. Chciałbym użyć forpętli zamiast, ponieważ forpętla sygnalizuje styl proceduralną, w której skutki uboczne są ważne.

Jeśli jednak absolutnie nalegasz na używanie funkcji list złożonych do wywoływania skutków ubocznych, powinieneś uniknąć nieefektywności, używając zamiast tego wyrażenia generatora. Jeśli absolutnie nalegasz na ten styl, wykonaj jedną z tych dwóch czynności:

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

lub:

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

Są to wyrażenia generatora, które nie generują losowej listy, która zostaje wyrzucona. Myślę, że allforma jest być może nieco bardziej przejrzysta, chociaż myślę, że oba są mylące i nie powinny być używane.

Myślę, że to jest brzydkie i nie zrobiłbym tego w kodzie. Ale jeśli nalegasz na implementację swoich pętli w ten sposób, tak bym to zrobił.

Wydaje mi się, że listy składane i im podobne powinny sygnalizować próbę użycia czegoś, co najmniej trochę przypominającego styl funkcjonalny. Umieszczanie rzeczy z efektami ubocznymi, które łamią to założenie, spowoduje, że ludzie będą musieli uważniej czytać twój kod i myślę, że to zła rzecz.