compréhension de la liste vs lambda + filtre

Je me suis trouvé avoir un besoin de filtrage de base: j'ai une liste et je dois la filtrer par un attribut des éléments.

Mon code ressemblait à ceci:

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

Mais alors j'ai pensé, ne serait-il pas préférable de l'écrire comme ça?

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

C'est plus lisible, et si nécessaire pour la performance, le lambda pourrait être retiré pour gagner quelque chose.

La question est: y a-t-il des réserves à utiliser la deuxième façon? Une différence de performance? Suis-je complètement absent du Pythonic Way ™ et dois-je le faire d'une autre manière (comme utiliser itemgetter au lieu du lambda)?

Il est étrange combien la beauté varie selon les personnes. Je trouve la compréhension de la liste beaucoup plus claire que filter+ lambda, mais utilisez celle que vous trouvez plus facilement.

Il y a deux choses qui peuvent ralentir votre utilisation filter.

Le premier est la surcharge de l'appel de fonction: dès que vous utilisez une fonction Python (qu'elle soit créée par defou lambda), il est probable que le filtre soit plus lent que la compréhension de la liste. Ce n'est certainement pas suffisant pour avoir de l'importance, et vous ne devriez pas penser beaucoup aux performances avant d'avoir chronométré votre code et trouvé qu'il s'agit d'un goulot d'étranglement, mais la différence sera là.

L'autre surcharge qui pourrait s'appliquer est que le lambda est forcé d'accéder à une variable de portée ( value). C'est plus lent que d'accéder à une variable locale et dans Python 2.x, la compréhension de la liste accède uniquement aux variables locales. Si vous utilisez Python 3.x, la compréhension de la liste s'exécute dans une fonction distincte, elle sera donc également accessible valuevia une fermeture et cette différence ne s'appliquera pas.

L'autre option à considérer est d'utiliser un générateur au lieu d'une compréhension de liste:

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

Ensuite, dans votre code principal (où la lisibilité importe vraiment), vous avez remplacé la compréhension de la liste et le filtre par un nom de fonction, espérons-le, significatif.

Il s'agit d'un problème quelque peu religieux en Python. Même si Guido a envisagé de supprimer map, filteret reducede Python 3 , il y avait suffisamment de jeu qui, à la fin, n'a reduceété déplacé des fonctions intégrées que vers functools.reduce .

Personnellement, je trouve les listes de compréhension plus faciles à lire. Il est plus explicite ce qui se passe à partir de l'expression [i for i in list if i.attribute == value]car tout le comportement est à la surface et non à l'intérieur de la fonction de filtre.

Je ne m'inquiéterais pas trop de la différence de performance entre les deux approches car elle est marginale. Je n'optimiserais vraiment cela que s'il s'avérait être le goulot d'étranglement dans votre application, ce qui est peu probable.

De plus, puisque le BDFL voulait sortirfilter du langage, cela rendait sûrement automatiquement les compréhensions de liste plus Pythonic ;-)

Étant donné que toute différence de vitesse est nécessairement minuscule, l'utilisation de filtres ou de listes de listes se résume à une question de goût. En général, je suis enclin à utiliser des compréhensions (ce qui semble être d'accord avec la plupart des autres réponses ici), mais il y a un cas où je préfèrefilter .

Un cas d'utilisation très fréquent consiste à extraire les valeurs de certains X itérables soumis à un prédicat P (x):

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

mais parfois vous voulez d'abord appliquer une fonction aux valeurs:

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

Comme exemple spécifique, considérez

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

Je pense que cela semble légèrement meilleur que l'utilisation filter. Mais considérez maintenant

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

Dans ce cas, nous voulons filtercomparer la valeur post-calculée. Outre le problème du calcul du cube deux fois (imaginez un calcul plus coûteux), il y a le problème de l'écriture de l'expression deux fois, violant la esthétique SEC . Dans ce cas, je serais apte à utiliser

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

Bien que cela filterpuisse être la "voie la plus rapide", la "voie Pythonic" ne serait pas de se soucier de telles choses à moins que les performances ne soient absolument critiques (auquel cas vous n'utiliseriez pas Python!).

Je pensais simplement ajouter qu'en python 3, filter () est en fait un objet itérateur, vous devez donc passer votre appel de méthode de filtrage à list () afin de construire la liste filtrée. Donc 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)

les listes b et c ont les mêmes valeurs et ont été complétées à peu près en même temps que filter () était équivalent [x pour x dans y si z]. Cependant, en 3, ce même code laisserait la liste c contenant un objet filtre, pas une liste filtrée. Pour produire les mêmes valeurs 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))

Le problème est que list () prend un itérable comme argument et crée une nouvelle liste à partir de cet argument. Le résultat est que l'utilisation de filtre de cette manière en python 3 prend jusqu'à deux fois plus de temps que la méthode [x pour x en y si z] car vous devez répéter la sortie de filter () ainsi que la liste d'origine.

Une différence importante est que la compréhension de la liste renverra un listtandis que le filtre renvoie un filter, que vous ne pouvez pas manipuler comme un list(c'est-à-dire: appeler lendessus, qui ne fonctionne pas avec le retour defilter ).

Mon auto-apprentissage m'a amené à un problème similaire.

Cela étant dit, s'il existe un moyen d'avoir le résultat listd'un filter, un peu comme vous le feriez dans .NET lorsque vous le faiteslst.Where(i => i.something()).ToList() , je suis curieux de le savoir.

EDIT: C'est le cas pour Python 3, pas 2 (voir la discussion dans les commentaires).

Je trouve la deuxième façon plus lisible. Il vous indique exactement quelle est l'intention: filtrer la liste.
PS: n'utilisez pas 'list' comme nom de variable

filterest généralement légèrement plus rapide si vous utilisez une fonction intégrée.

Je m'attendrais à ce que la compréhension de la liste soit légèrement plus rapide dans votre cas

Le filtre n'est que cela. Il filtre les éléments d'une liste. Vous pouvez voir que la définition mentionne la même chose (dans le lien de documentation officiel que j'ai mentionné précédemment). Alors que la compréhension de liste est quelque chose qui produit une nouvelle liste après avoir agi sur quelque chose de la liste précédente. , par exemple, un type de données entièrement nouveau. Comme la conversion d'entiers en chaîne, etc.)

Dans votre exemple, il est préférable d'utiliser le filtre que la compréhension de liste, selon la définition. Cependant, si vous le souhaitez, par exemple other_attribute à partir des éléments de la liste, dans votre exemple doit être récupéré en tant que nouvelle liste, vous pouvez utiliser la compréhension de la liste.

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

C'est ainsi que je me souviens de la compréhension des filtres et des listes. Supprimez quelques éléments d'une liste et conservez les autres éléments intacts, utilisez le filtre. Utilisez vous-même un peu de logique au niveau des éléments et créez une liste édulcorée adaptée à un objectif, utilisez la compréhension de la liste.

Voici une courte pièce que j'utilise lorsque j'ai besoin de filtrer quelque chose après la compréhension de la liste. Juste une combinaison de filtre, lambda et listes (autrement connu comme la loyauté d'un chat et la propreté d'un chien).

Dans ce cas, je lis un fichier, je supprime les lignes vides, les lignes commentées et tout ce qui suit un commentaire sur une ligne:

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

En plus de la réponse acceptée, il y a un cas d'angle où vous devez utiliser un filtre au lieu d'une compréhension de liste. Si la liste n'est pas partageable, vous ne pouvez pas la traiter directement avec une compréhension de liste. Un exemple réel est si vous utilisez pyodbcpour lire les résultats d'une base de données. Le fetchAll()résultat cursorest une liste non partageable. Dans cette situation, pour manipuler directement les résultats retournés, un filtre doit être utilisé:

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 vous utilisez la compréhension de liste ici, vous obtiendrez l'erreur:

TypeError: type non partageable: 'liste'

Il m'a fallu un certain temps pour me familiariser avec le higher order functions filteret map. Alors je filterme suis habitué à eux et j'ai vraiment aimé car il était explicite qu'il filtre en gardant ce qui est vrai et je me sentais cool que j'en connaissaisfunctional programming termes.

J'ai ensuite lu ce passage (Fluent Python Book):

Les fonctions de carte et de filtre sont toujours intégrées dans Python 3, mais depuis l'introduction des listes de compréhension et des expressions de générateur, elles ne sont pas aussi importantes. Un listcomp ou un genexp fait le travail de la carte et du filtre combinés, mais est plus lisible.

Et maintenant, je pense, pourquoi s'embêter avec le concept de filter/ mapsi vous pouvez y parvenir avec des idiomes déjà largement répandus comme les listes de compréhension. De plus maps, ce filterssont des fonctions. Dans ce cas, je préfère utiliser des Anonymous functionslambdas.

Enfin, juste pour le faire tester, j'ai chronométré les deux méthodes ( mapet listComp) et je n'ai vu aucune différence de vitesse pertinente qui justifierait de faire des arguments à ce sujet.

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

Curieusement sur Python 3, je vois que le filtre fonctionne plus rapidement que les compréhensions de liste.

J'ai toujours pensé que les listes de compréhension seraient plus performantes. Quelque chose comme: [nom pour le nom dans brand_names_db si le nom n'est pas None] Le bytecode généré est un peu meilleur.

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

Mais ils sont en réalité plus lents:

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

Ma prise

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