rozumienie listy vs. lambda + filtr

Zdarzyło mi się, że mam podstawową potrzebę filtrowania: mam listę i muszę ją filtrować według atrybutu elementów.

Mój kod wyglądał tak:

my_list = [x for x in my_list if x.attribute == value]

Ale potem pomyślałem, czy nie byłoby lepiej tak napisać?

my_list = filter(lambda x: x.attribute == value, my_list)

Jest bardziej czytelny, a w razie potrzeby można wyjąć lambda, aby coś zyskać.

Pytanie brzmi: czy są jakieś zastrzeżenia dotyczące korzystania z drugiego sposobu? Jakaś różnica w wydajności? Czy całkowicie brakuje mi Pythonic Way ™ i czy powinienem to zrobić w jeszcze inny sposób (np. Używając itemgetter zamiast lambda)?

Dziwne, jak różne jest piękno u różnych ludzi. Uważam, że lista jest znacznie bardziej zrozumiała niż filter+ lambda, ale używaj tego, co uznasz za łatwiejsze.

Są dwie rzeczy, które mogą spowolnić twoje użycie filter.

Pierwszym z nich jest narzut wywołania funkcji: jak tylko użyjesz funkcji Python (utworzonej przez deflub lambda), prawdopodobnie filtr będzie wolniejszy niż przetwarzanie listy. Prawie na pewno nie wystarczy, aby mieć znaczenie, i nie powinieneś dużo myśleć o wydajności, dopóki nie zorientujesz się w swoim kodzie i nie okaże się, że to wąskie gardło, ale będzie różnica.

Innym narzutem, który może mieć zastosowanie, jest to, że lambda jest zmuszona uzyskać dostęp do zmiennej o zasięgu ( value). Jest to wolniejsze niż uzyskiwanie dostępu do zmiennej lokalnej, a w Pythonie 2.x analiza listy ma dostęp tylko do zmiennych lokalnych. Jeśli używasz języka Python 3.x, lista jest uruchamiana w osobnej funkcji, więc dostęp do niej będzie również uzyskiwany valuepoprzez zamknięcie i ta różnica nie będzie miała zastosowania.

Inną opcją do rozważenia jest użycie generatora zamiast zrozumienia listy:

def filterbyvalue(seq, value):
   for el in seq:
       if el.attribute==value: yield el

Następnie w swoim głównym kodzie (gdzie liczy się czytelność) zastąpiłeś zarówno rozumienie listy, jak i filtr, miejmy nadzieję, znaczącą nazwę funkcji.

Jest to dość religijna kwestia w Pythonie. Mimo że Guido rozważał usunięcie map, filteraw reducePythonie 3 było dość luzu, który ostatecznie reducezostał przeniesiony tylko z wbudowanych do funools.reduce .

Osobiście uważam, że listy są łatwiejsze do odczytania. Bardziej wyraźne jest to, co dzieje się z wyrażeniem, [i for i in list if i.attribute == value]ponieważ całe zachowanie jest na powierzchni, a nie wewnątrz funkcji filtra.

Nie martwiłbym się zbytnio różnicą wydajności między tymi dwoma podejściami, ponieważ jest ona marginalna. Naprawdę zoptymalizowałbym to tylko, gdyby okazało się, że jest to wąskie gardło w twojej aplikacji, co jest mało prawdopodobne.

Również dlatego, że BDFL chciał filterodejść od języka, to z pewnością automatycznie czyni listy ze zrozumiałymi pythonami ;-)

Ponieważ jakakolwiek różnica prędkości musi być niewielka, to czy użyć filtrów, czy też list, sprowadza się to do gustu. Ogólnie rzecz biorąc, jestem skłonny używać rozumienia (co wydaje się zgadzać z większością innych odpowiedzi tutaj), ale jest jeden przypadek, w którym wolę filter.

Bardzo częstym przypadkiem użycia jest wyciągnięcie wartości jakiegoś iterowalnego X z zastrzeżeniem predykatu P (x):

[x for x in X if P(x)]

ale czasami chcesz najpierw zastosować jakąś funkcję do wartości:

[f(x) for x in X if P(f(x))]

Jako konkretny przykład rozważmy

primes_cubed = [x*x*x for x in range(1000) if prime(x)]

Myślę, że wygląda to nieco lepiej niż używanie filter. Ale teraz zastanów się

prime_cubes = [x*x*x for x in range(1000) if prime(x*x*x)]

W tym przypadku chcemy filterprzeciw obliczonej wartości obliczonej. Oprócz kwestii dwukrotnego obliczenia kostki (wyobraź sobie droższe obliczenia), istnieje także kwestia dwukrotnego napisania wyrażenia, co narusza estetykę SUCHEGO . W takim przypadku byłbym skłonny użyć

prime_cubes = filter(prime, [x*x*x for x in range(1000)])

Chociaż filtermoże to być „szybszy sposób”, „pytonicznym sposobem” byłoby nie przejmowanie się takimi rzeczami, chyba że wydajność jest absolutnie krytyczna (w takim przypadku nie używałbyś Pythona!).

Pomyślałem, że po prostu dodam, że w Pythonie 3 filter () jest w rzeczywistości obiektem iteratora, więc musisz zbudować filtrowaną listę do wywołania metody filter do list (). Tak więc w python 2:

lst_a = range(25) #arbitrary list
lst_b = [num for num in lst_a if num % 2 == 0]
lst_c = filter(lambda num: num % 2 == 0, lst_a)

listy b i c mają te same wartości i zostały uzupełnione mniej więcej w tym samym czasie, gdy filter () był równoważny [x dla x in y, jeśli z]. Jednak w 3 ten sam kod pozostawiłby listę c zawierającą obiekt filtrujący, a nie filtrowaną listę. Aby wygenerować te same wartości w 3:

lst_a = range(25) #arbitrary list
lst_b = [num for num in lst_a if num % 2 == 0]
lst_c = list(filter(lambda num: num %2 == 0, lst_a))

Problem polega na tym, że list () przyjmuje iterowalny argument i tworzy nową listę z tego argumentu. Powoduje to, że użycie filtru w ten sposób w Pythonie 3 zajmuje nawet dwukrotnie więcej czasu niż metoda [x for x in y if z], ponieważ musisz iterować dane wyjściowe z filter (), a także oryginalną listę.

Istotną różnicą jest to, że zrozumienie listy zwróci listchwilę, podczas gdy filtr zwróci a filter, którego nie można manipulować jak list(tj. Wywołanie lengo, które nie działa z powrotemfilter ).

Mój własny proces uczenia się doprowadził mnie do podobnego problemu.

Biorąc to pod uwagę, jeśli istnieje sposób, aby uzyskać wynik listz filter, trochę tak jak zrobiłbyś w .NET, kiedy to zrobiszlst.Where(i => i.something()).ToList() , jestem ciekawy, aby to wiedzieć.

EDYCJA: Tak jest w przypadku Pythona 3, a nie 2 (patrz dyskusja w komentarzach).

Drugi sposób uważam za bardziej czytelny. Mówi dokładnie, jaki jest zamiar: przefiltruj listę.
PS: nie używaj „listy” jako nazwy zmiennej

ogólnie filterjest nieco szybszy, jeśli używasz wbudowanej funkcji.

Spodziewałbym się, że lista będzie nieco szybsza w twoim przypadku

Filtr jest właśnie taki. Filtruje elementy listy. Możesz zobaczyć, że definicja wspomina to samo (w oficjalnym linku do dokumentów, o którym wspomniałem wcześniej). Podczas gdy rozumienie listy jest czymś, co tworzy nową listę po działaniu na coś z poprzedniej listy (zarówno filtrowanie, jak i rozumienie listy tworzy nową listę i nie wykonuje operacji zamiast starszej listy. Nowa lista tutaj jest czymś w rodzaju listy z , powiedzmy, zupełnie nowy typ danych. Jak konwersja liczb całkowitych na ciąg itp.)

W twoim przykładzie lepiej jest używać filtrowania niż listowania, zgodnie z definicją. Jeśli jednak chcesz, powiedzmy inny atrybut z elementów listy, w twoim przykładzie ma zostać pobrana jako nowa lista, możesz użyć rozumienia listy.

return [item.other_attribute for item in my_list if item.attribute==value]

Tak właśnie pamiętam o analizie filtrów i list. Usuń kilka rzeczy z listy i pozostań nienaruszonych, użyj filtru. Skorzystaj z własnej logiki przy elementach i stwórz rozwodnioną listę odpowiednią do określonego celu, skorzystaj ze zrozumienia listy.

Oto krótki fragment, którego używam, gdy muszę odfiltrować coś po z listą. Po prostu kombinacja filtra, lambda i list (zwana także lojalnością kota i czystością psa).

W tym przypadku czytam plik, usuwam puste linie, komentuję linie i wszystko po komentarzu do linii:

# Throw out blank lines and comments
with open('file.txt', 'r') as lines:        
    # From the inside out:
    #    [s.partition('#')[0].strip() for s in lines]... Throws out comments
    #   filter(lambda x: x!= '', [s.part... Filters out blank lines
    #  y for y in filter... Converts filter object to list
    file_contents = [y for y in filter(lambda x: x != '', [s.partition('#')[0].strip() for s in lines])]

Oprócz zaakceptowanej odpowiedzi istnieje przypadek narożny, w którym należy użyć filtru zamiast listy. Jeśli listy nie da się zhashować, nie można jej przetworzyć bezpośrednio ze zrozumieniem listy. Rzeczywistym przykładem jest sytuacja, gdy używasz pyodbcdo odczytu wyników z bazy danych. Te fetchAll()wyniki cursorto lista unhashable. W tej sytuacji, aby bezpośrednio manipulować zwróconymi wynikami, należy użyć filtru:

cursor.execute("SELECT * FROM TABLE1;")
data_from_db = cursor.fetchall()
processed_data = filter(lambda s: 'abc' in s.field1 or s.StartTime >= start_date_time, data_from_db) 

Jeśli użyjesz tutaj rozumienia listy, pojawi się błąd:

TypeError: unhashable type: 'list'

Zajęło mi trochę czasu, aby zapoznać się z higher order functions filteri map. Więc przyzwyczaiłem się do nich i naprawdę mi się podobało, filterponieważ było jasne, że filtruje, zachowując wszystko, co jest prawdą, i czułem się fajnie, że znałem niektóre functional programmingwarunki.

Potem czytam ten fragment (Fluent Python Book):

Funkcje mapowania i filtrowania są nadal wbudowane w Pythona 3, ale od czasu wprowadzenia list i wyrażeń generatora nie są one tak ważne. Listcomp lub genexp wykonują zadanie mapowania i filtrowania łącznie, ale są bardziej czytelne.

A teraz myślę, po co zawracać sobie głowę koncepcją filter/ mapjeśli możesz to osiągnąć dzięki już szeroko rozpowszechnionym idiomom, takim jak listy. Ponadto mapsi filterssą rodzajem funkcji. W tym przypadku wolę używać Anonymous functionslambda.

Wreszcie, tylko ze względu na przetestowanie, określiłem obie metody ( mapi listComp) i nie zauważyłem żadnej istotnej różnicy prędkości, która uzasadniałaby argumentowanie na ten temat.

from timeit import Timer

timeMap = Timer(lambda: list(map(lambda x: x*x, range(10**7))))
print(timeMap.timeit(number=100))

timeListComp = Timer(lambda:[(lambda x: x*x) for x in range(10**7)])
print(timeListComp.timeit(number=100))

#Map:                 166.95695265199174
#List Comprehension   177.97208347299602

Co ciekawe, w Pythonie 3 widzę, że filtr działa szybciej niż wyrażenia listowe.

Zawsze myślałem, że listy będą bardziej wydajne. Coś w stylu: [nazwa dla nazwy w brand_names_db, jeśli nazwa nie jest Brak] Wygenerowany kod bajtowy jest nieco lepszy.

>>> def f1(seq):
...     return list(filter(None, seq))
>>> def f2(seq):
...     return [i for i in seq if i is not None]
>>> disassemble(f1.__code__)
2         0 LOAD_GLOBAL              0 (list)
          2 LOAD_GLOBAL              1 (filter)
          4 LOAD_CONST               0 (None)
          6 LOAD_FAST                0 (seq)
          8 CALL_FUNCTION            2
         10 CALL_FUNCTION            1
         12 RETURN_VALUE
>>> disassemble(f2.__code__)
2           0 LOAD_CONST               1 (<code object <listcomp> at 0x10cfcaa50, file "<stdin>", line 2>)
          2 LOAD_CONST               2 ('f2.<locals>.<listcomp>')
          4 MAKE_FUNCTION            0
          6 LOAD_FAST                0 (seq)
          8 GET_ITER
         10 CALL_FUNCTION            1
         12 RETURN_VALUE

Ale w rzeczywistości są wolniejsze:

   >>> timeit(stmt="f1(range(1000))", setup="from __main__ import f1,f2")
   21.177661532000116
   >>> timeit(stmt="f2(range(1000))", setup="from __main__ import f1,f2")
   42.233950221000214

Moje podanie

def filter_list(list, key, value, limit=None):
    return [i for i in list if i[key] == value][:limit]