lista de comprensión vs. lambda + filtro

Me encontré con una necesidad básica de filtrado: tengo una lista y tengo que filtrarla por un atributo de los elementos.

Mi código se veía así:

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

Pero luego pensé, ¿no sería mejor escribirlo así?

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

Es más legible, y si es necesario para el rendimiento, se podría sacar la lambda para obtener algo.

La pregunta es: ¿hay alguna advertencia al usar la segunda forma? ¿Alguna diferencia de rendimiento? ¿Me estoy perdiendo el Pythonic Way ™ por completo y debería hacerlo de otra manera (como usar itemgetter en lugar de lambda)?

Es extraño cuánto varía la belleza para diferentes personas. Encuentro la comprensión de la lista mucho más clara que filter+ lambda, pero use la que le resulte más fácil.

Hay dos cosas que pueden retrasar su uso filter.

El primero es la sobrecarga de la llamada de función: tan pronto como use una función de Python (ya sea creada por defo lambda) es probable que el filtro sea más lento que la comprensión de la lista. Es casi seguro que no sea suficiente, y no debe pensar mucho en el rendimiento hasta que haya cronometrado su código y haya encontrado que es un cuello de botella, pero la diferencia estará ahí.

La otra sobrecarga que podría aplicarse es que la lambda se ve obligada a acceder a una variable de ámbito ( value). Eso es más lento que acceder a una variable local y en Python 2.x la comprensión de la lista solo accede a las variables locales. Si está utilizando Python 3.x, la comprensión de la lista se ejecuta en una función separada, por lo que también se accederá a valuetravés de un cierre y esta diferencia no se aplicará.

La otra opción a considerar es usar un generador en lugar de una lista de comprensión:

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

Luego, en su código principal (que es donde la legibilidad realmente importa) ha reemplazado tanto la comprensión de la lista como el filtro con un nombre de función con significado significativo.

Este es un tema algo religioso en Python. A pesar de que Guido consideró eliminarlo map, filtery reducede Python 3 , hubo suficiente reacción violenta que al final solo reducese movió de las funciones integradas a functools.reduce .

Personalmente, encuentro las comprensiones de listas más fáciles de leer. Es más explícito lo que está sucediendo en la expresión, [i for i in list if i.attribute == value]ya que todo el comportamiento está en la superficie, no dentro de la función de filtro.

No me preocuparía demasiado la diferencia de rendimiento entre los dos enfoques, ya que es marginal. Realmente solo optimizaría esto si resultara ser el cuello de botella en su aplicación, lo cual es poco probable.

Además, dado que el BDFL quería filterpasar del lenguaje, seguramente eso automáticamente hace que las comprensiones de listas sean más pitónicas ;-)

Dado que cualquier diferencia de velocidad está destinada a ser minúscula, usar filtros o comprender las listas se reduce a una cuestión de gustos. En general, me inclino a usar las comprensiones (que parece estar de acuerdo con la mayoría de las otras respuestas aquí), pero hay un caso en el que prefiero filter.

Un caso de uso muy frecuente es extraer los valores de algún X iterable sujeto a un predicado P (x):

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

pero a veces quieres aplicar alguna función a los valores primero:

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

Como ejemplo específico, considere

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

Creo que esto se ve un poco mejor que usar filter. Pero ahora considera

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

En este caso queremos filtercontra el valor post-calculado. Además del problema de calcular el cubo dos veces (imagine un cálculo más costoso), está el problema de escribir la expresión dos veces, violando la estética DRY . En este caso, sería apto para usar

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

Aunque filterpuede ser la "forma más rápida", la "forma pitónica" sería no preocuparse por esas cosas a menos que el rendimiento sea absolutamente crítico (¡en cuyo caso no estaría usando Python!).

Pensé que solo agregaría que en Python 3, filter () es en realidad un objeto iterador, por lo que tendría que pasar su llamada al método de filtro a list () para construir la lista filtrada. Entonces en 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)

las listas byc tienen los mismos valores, y se completaron aproximadamente al mismo tiempo que filter () era equivalente [x para x en y si z]. Sin embargo, en 3, este mismo código dejaría la lista c que contiene un objeto de filtro, no una lista filtrada. Para producir los mismos valores en 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))

El problema es que list () toma un iterable como argumento y crea una nueva lista a partir de ese argumento. El resultado es que usar el filtro de esta manera en Python 3 toma hasta el doble de tiempo que el método [x para x en y si z] porque debe iterar sobre la salida del filtro (), así como la lista original.

Una diferencia importante es que la comprensión de la lista devolverá un listtiempo, mientras que el filtro devuelve un filter, que no puede manipular como un list(es decir, invocarlo len, que no funciona con el retorno de filter).

Mi propio autoaprendizaje me llevó a un problema similar.

Dicho esto, si hay una manera de obtener el resultado listde un filter, un poco como lo haría en .NET cuando lo haga lst.Where(i => i.something()).ToList(), tengo curiosidad por saberlo.

EDITAR: Este es el caso de Python 3, no 2 (ver discusión en los comentarios).

Encuentro la segunda forma más legible. Te dice exactamente cuál es la intención: filtrar la lista.
PD: no use 'lista' como nombre de variable

generalmente filteres un poco más rápido si se usa una función integrada.

Esperaría que la comprensión de la lista sea un poco más rápida en su caso

El filtro es solo eso. Filtra los elementos de una lista. Puede ver que la definición menciona lo mismo (en el enlace de documentos oficiales que mencioné antes). Mientras que la comprensión de la lista es algo que produce una nueva lista después de actuar sobre algo de la lista anterior. , digamos, un tipo de datos completamente nuevo. Como convertir enteros a cadenas, etc.)

En su ejemplo, es mejor usar filtro que comprensión de listas, según la definición. Sin embargo, si lo desea, diga other_attribute de los elementos de la lista, en su ejemplo se debe recuperar como una nueva lista, entonces puede usar la comprensión de la lista.

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

Así es como realmente recuerdo acerca de la comprensión de filtros y listas. Elimine algunas cosas dentro de una lista y mantenga los otros elementos intactos, use filtro. Use un poco de lógica por su cuenta en los elementos y cree una lista diluida adecuada para algún propósito, use la comprensión de la lista.

Aquí hay una pieza corta que uso cuando necesito filtrar algo después de la comprensión de la lista. Solo una combinación de filtro, lambda y listas (también conocida como la lealtad de un gato y la limpieza de un perro).

En este caso, estoy leyendo un archivo, eliminando líneas en blanco, líneas comentadas y cualquier cosa después de un comentario en una línea:

# 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])]

Además de la respuesta aceptada, hay un caso de esquina en el que debe usar filtro en lugar de una comprensión de lista. Si la lista no se puede compartir, no puede procesarla directamente con una comprensión de la lista. Un ejemplo del mundo real es si usas pyodbcpara leer resultados de una base de datos. Los fetchAll()resultados de cursores una lista inquebrantable. En esta situación, para manipular directamente los resultados devueltos, se debe utilizar el filtro:

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) 

Si utiliza la comprensión de la lista aquí, obtendrá el error:

TypeError: tipo no compartible: 'lista'

Me tomó un tiempo familiarizarme con el higher order functions filtery map. Así que me acostumbré a ellos y en realidad me gustó, filterya que era explícito que se filtra manteniendo lo que es verdadero y me sentí bien al saber algunos functional programmingtérminos.

Luego leí este pasaje (Fluent Python Book):

Las funciones de mapa y filtro todavía están integradas en Python 3, pero desde la introducción de las comprensiones de listas y las expresiones de generador, no son tan importantes. Un listcomp o un genexp hace el trabajo de mapa y filtro combinados, pero es más legible.

Y ahora pienso, ¿por qué molestarse con el concepto de filter/ mapsi puede lograrlo con expresiones idiomáticas ya ampliamente difundidas como las comprensiones de listas? Además mapsy filtersson un tipo de funciones. En este caso prefiero usar Anonymous functionslambdas.

Finalmente, solo por el hecho de haberlo probado, he cronometrado ambos métodos ( mapy listComp) y no vi ninguna diferencia de velocidad relevante que justificara hacer argumentos al respecto.

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

Curiosamente en Python 3, veo que el filtro funciona más rápido que las listas de comprensión.

Siempre pensé que las comprensiones de la lista serían más efectivas. Algo así como: [nombre para el nombre en brand_names_db si el nombre no es Ninguno] El código de bytes generado es un poco mejor.

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

Pero en realidad son más lentos:

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

Mi toma

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