Compréhension de liste vs carte

Question

Y a-t-il une raison de préférer utiliser map() sur la compréhension des listes ou vice versa ? L'un ou l'autre est-il généralement plus efficace ou considéré comme plus pythique que l'autre ?

Answer 1

map peut être microscopiquement plus rapide dans certains cas (lorsque vous ne créez PAS un lambda dans ce but, mais que vous utilisez la même fonction dans map et dans une comprehension de liste). Les compréhensions de listes peuvent être plus rapides dans d'autres cas et la plupart (pas tous) des pythonistes les considèrent plus directes et plus claires.

Un exemple de l'avantage minuscule de rapidité de map lorsqu'on utilise exactement la même fonction :

$ python -m timeit -s'xs=range(10)' 'map(hex, xs)'
100000 loops, best of 3: 4.86 usec per loop
$ python -m timeit -s'xs=range(10)' '[hex(x) for x in xs]'
100000 loops, best of 3: 5.58 usec per loop

Un exemple de la façon dont la comparaison des performances est complètement inversée lorsque map a besoin d'un lambda :

$ python -m timeit -s'xs=range(10)' 'map(lambda x: x+2, xs)'
100000 loops, best of 3: 4.24 usec per loop
$ python -m timeit -s'xs=range(10)' '[x+2 for x in xs]'
100000 loops, best of 3: 2.32 usec per loop

Answer 2

Cas

• Cas commun : Dans la plupart des cas, vous voudrez utiliser une liste de compréhension en python car ce que vous faites sera plus évident pour les programmeurs novices qui lisent votre code. (Ceci ne s'applique pas aux autres langages, où d'autres idiomes peuvent s'appliquer). Ce que vous faites sera même plus évident pour les programmeurs python, puisque les compréhensions de listes sont la norme de facto en python pour l'itération ; elles sont les suivantes attendu .

• Cas moins fréquent : Cependant, si vous ont déjà une fonction définie il est souvent raisonnable d'utiliser map bien qu'il soit considéré comme "non pythonique". Par exemple, map(sum, myLists) est plus élégant/terse que [sum(x) for x in myLists] . Vous gagnez l'élégance de ne pas avoir à inventer une variable fictive (par ex. sum(x) for x... o sum(_) for _... o sum(readableName) for readableName... ) que vous devez taper deux fois, juste pour itérer. Le même argument vaut pour filter y reduce et tout ce qui concerne le itertools module : si vous avez déjà une fonction à portée de main, vous pouvez aller de l'avant et faire de la programmation fonctionnelle. Cela permet de gagner en lisibilité dans certaines situations, et d'en perdre dans d'autres (par exemple, programmeurs novices, arguments multiples)... mais la lisibilité de votre code dépend fortement de vos commentaires de toute façon.

• Presque jamais. : Vous pouvez utiliser le map comme une fonction abstraite pure tout en faisant de la programmation fonctionnelle, où vous mettez en correspondance map ou le curry map ou bénéficier d'une discussion sur map comme une fonction. En Haskell par exemple, une interface de type foncteur appelée fmap généralise le mappage sur n'importe quelle structure de données. C'est très rare en python parce que la grammaire python vous oblige à utiliser le style générateur pour parler de l'itération ; vous ne pouvez pas le généraliser facilement. (C'est parfois une bonne et parfois une mauvaise chose.) Vous pouvez probablement trouver de rares exemples en python où map(f, *lists) est une chose raisonnable à faire. L'exemple le plus proche que je puisse trouver est le suivant sumEach = partial(map,sum) ce qui équivaut à peu près à :

  def sumEach(myLists): return [sum() for in myLists]

• Il suffit d'utiliser un for -boucle : Vous pouvez aussi bien sûr simplement utiliser une boucle for. Bien qu'elles ne soient pas aussi élégantes du point de vue de la programmation fonctionnelle, les variables non-locales rendent parfois le code plus clair dans les langages de programmation impératifs tels que python, car les gens sont habitués à lire le code de cette manière. Les for-loops sont aussi, généralement, les plus efficaces lorsque vous faites simplement une opération complexe qui n'est pas la construction d'une liste comme les comprehensions de liste et map sont optimisées pour (par exemple additionner, ou faire un arbre, etc.) -- au moins efficace en termes de mémoire (pas nécessairement en termes de temps, où je m'attendrais au pire à un facteur constant, à moins d'un rare hoquet pathologique de garbage-collection).

"Pythonisme"

Je n'aime pas le mot "python" car je ne trouve pas que le python soit toujours élégant à mes yeux. Néanmoins, map y filter et des fonctions similaires (comme la très utile itertools ) sont probablement considérés comme non pythoniques en termes de style.

Paresse

En termes d'efficacité, comme la plupart des constructions de programmation fonctionnelle, LA CARTE PEUT ÊTRE PARESSEUSE et est en fait paresseux en python. Cela signifie que vous pouvez faire ceci (dans python3 ) et votre ordinateur ne manquera pas de mémoire et ne perdra pas toutes vos données non sauvegardées :

>>> map(str, range(10**100))
<map object at 0x2201d50>

Essayez de faire ça avec la compréhension d'une liste :

>>> [str(n) for n in range(10**100)]
# DO NOT TRY THIS AT HOME OR YOU WILL BE SAD #

Notez que les comprehensions de listes sont aussi intrinsèquement paresseuses, mais python a choisi de les implémenter comme non-lazy. . Néanmoins, python prend en charge les compréhensions de listes paresseuses sous la forme d'expressions de générateur, comme suit :

>>> (str(n) for n in range(10**100))
<generator object <genexpr> at 0xacbdef>

En gros, vous pouvez penser à la [...] comme le passage d'une expression de générateur au constructeur de liste, comme list(x for x in range(5)) .

Bref exemple artificiel

from operator import neg
print({x:x**2 for x in map(neg,range(5))})

print({x:x**2 for x in [-y for y in range(5)]})

print({x:x**2 for x in (-y for y in range(5))})

Les compréhensions de liste sont non-lazy, et peuvent donc nécessiter plus de mémoire (à moins que vous n'utilisiez des compréhensions de générateur). Les crochets [...] rendent souvent les choses évidentes, surtout lorsqu'elles se trouvent dans un fouillis de parenthèses. D'un autre côté, il arrive que l'on finisse par être verbeux, comme en tapant [x for x in... . Tant que vous gardez vos variables d'itérateurs courtes, les compréhensions de listes sont généralement plus claires si vous n'indentez pas votre code. Mais vous pouvez toujours indenter votre code.

print(
    {x:x**2 for x in (-y for y in range(5))}
)

ou de casser les choses :

rangeNeg5 = (-y for y in range(5))
print(
    {x:x**2 for x in rangeNeg5}
)

Comparaison de l'efficacité de python3

map est maintenant paresseux :

% python3 -mtimeit -s 'xs=range(1000)' 'f=lambda x:x' 'z=map(f,xs)'
1000000 loops, best of 3: 0.336 usec per loop            ^^^^^^^^^

Par conséquent, si vous n'allez pas utiliser toutes vos données, ou si vous ne savez pas à l'avance de combien de données vous avez besoin, map en python3 (et les expressions de générateur en python2 ou python3) éviteront de calculer leurs valeurs jusqu'au dernier moment nécessaire. Habituellement, cela l'emportera sur la surcharge due à l'utilisation de map . L'inconvénient est que cela est très limité en python par rapport à la plupart des langages fonctionnels : vous ne bénéficiez de cet avantage que si vous accédez à vos données de gauche à droite "dans l'ordre", car les expressions du générateur python ne peuvent être évaluées que dans l'ordre suivant x[0], x[1], x[2], ... .

Toutefois, disons que nous avons une fonction préétablie f nous aimerions map et nous ignorons la paresse de map en forçant immédiatement l'évaluation avec list(...) . Nous obtenons des résultats très intéressants :

% python3 -mtimeit -s 'xs=range(1000)' 'f=lambda x:x' 'z=list(map(f,xs))'                                                                                                                                                
10000 loops, best of 3: 165/124/135 usec per loop        ^^^^^^^^^^^^^^^
                    for list(<map object>)

% python3 -mtimeit -s 'xs=range(1000)' 'f=lambda x:x' 'z=[f(x) for x in xs]'                                                                                                                                      
10000 loops, best of 3: 181/118/123 usec per loop        ^^^^^^^^^^^^^^^^^^
                    for list(<generator>), probably optimized

% python3 -mtimeit -s 'xs=range(1000)' 'f=lambda x:x' 'z=list(f(x) for x in xs)'                                                                                                                                    
1000 loops, best of 3: 215/150/150 usec per loop         ^^^^^^^^^^^^^^^^^^^^^^
                    for list(<generator>)

Les résultats sont de la forme AAA/BBB/CCC, où A a été réalisé sur une station de travail Intel datant de 2010 avec python 3. ?.?, et B et C ont été réalisés sur une station de travail AMD datant de 2013 avec python 3.2.1, avec un matériel extrêmement différent. Le résultat semble être que les compréhensions de cartes et de listes sont comparables en termes de performances, qui sont plus fortement affectées par d'autres facteurs aléatoires. La seule chose que nous pouvons dire semble être que, bizarrement, alors que nous nous attendons à ce que les compréhensions de listes [...] pour obtenir de meilleurs résultats que les expressions génératrices (...) , map est AUSSI plus efficace que les expressions de générateur (encore une fois en supposant que toutes les valeurs sont évaluées/utilisées).

Il est important de réaliser que ces tests supposent une fonction très simple (la fonction d'identité) ; cependant, c'est très bien ainsi car si la fonction était compliquée, le surcoût de performance serait négligeable par rapport aux autres facteurs du programme. (Il peut toujours être intéressant de tester avec d'autres choses simples comme f=lambda x:x+x )

Si vous savez lire l'assemblage python, vous pouvez utiliser la fonction dis module pour voir si c'est vraiment ce qui se passe en coulisses :

>>> listComp = compile('[f(x) for x in xs]', 'listComp', 'eval')
>>> dis.dis(listComp)
  1           0 LOAD_CONST               0 (<code object <listcomp> at 0x2511a48, file "listComp", line 1>) 
              3 MAKE_FUNCTION            0 
              6 LOAD_NAME                0 (xs) 
              9 GET_ITER             
             10 CALL_FUNCTION            1 
             13 RETURN_VALUE         
>>> listComp.co_consts
(<code object <listcomp> at 0x2511a48, file "listComp", line 1>,)
>>> dis.dis(listComp.co_consts[0])
  1           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                18 (to 27) 
              9 STORE_FAST               1 (x) 
             12 LOAD_GLOBAL              0 (f) 
             15 LOAD_FAST                1 (x) 
             18 CALL_FUNCTION            1 
             21 LIST_APPEND              2 
             24 JUMP_ABSOLUTE            6 
        >>   27 RETURN_VALUE

>>> listComp2 = compile('list(f(x) for x in xs)', 'listComp2', 'eval')
>>> dis.dis(listComp2)
  1           0 LOAD_NAME                0 (list) 
              3 LOAD_CONST               0 (<code object <genexpr> at 0x255bc68, file "listComp2", line 1>) 
              6 MAKE_FUNCTION            0 
              9 LOAD_NAME                1 (xs) 
             12 GET_ITER             
             13 CALL_FUNCTION            1 
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE         
>>> listComp2.co_consts
(<code object <genexpr> at 0x255bc68, file "listComp2", line 1>,)
>>> dis.dis(listComp2.co_consts[0])
  1           0 LOAD_FAST                0 (.0) 
        >>    3 FOR_ITER                17 (to 23) 
              6 STORE_FAST               1 (x) 
              9 LOAD_GLOBAL              0 (f) 
             12 LOAD_FAST                1 (x) 
             15 CALL_FUNCTION            1 
             18 YIELD_VALUE          
             19 POP_TOP              
             20 JUMP_ABSOLUTE            3 
        >>   23 LOAD_CONST               0 (None) 
             26 RETURN_VALUE

>>> evalledMap = compile('list(map(f,xs))', 'evalledMap', 'eval')
>>> dis.dis(evalledMap)
  1           0 LOAD_NAME                0 (list) 
              3 LOAD_NAME                1 (map) 
              6 LOAD_NAME                2 (f) 
              9 LOAD_NAME                3 (xs) 
             12 CALL_FUNCTION            2 
             15 CALL_FUNCTION            1 
             18 RETURN_VALUE 

Il semble qu'il soit préférable d'utiliser [...] syntaxe que list(...) . Malheureusement, le map est un peu opaque au désassemblage, mais nous pouvons nous contenter de notre test de vitesse.

Answer 3

Python 2 : Vous devez utiliser map y filter au lieu des compréhensions de listes.

Un site objectif La raison pour laquelle vous devriez les préférer, même s'ils ne sont pas "pythoniques", est la suivante :
Ils requièrent des fonctions/lambdas comme arguments, qui introduire un nouveau champ d'application .

Je me suis fait piquer par ça plus d'une fois :

for x, y in somePoints:
    # (several lines of code here)
    squared = [x ** 2 for x in numbers]
    # Oops, x was silently overwritten!

mais si à la place j'avais dit :

for x, y in somePoints:
    # (several lines of code here)
    squared = map(lambda x: x ** 2, numbers)

alors tout aurait été parfait.

On pourrait dire que j'ai été stupide d'utiliser le même nom de variable dans la même portée.

Je ne l'étais pas. Le code était bien à l'origine - les deux x n'étaient pas dans le même périmètre.
C'est seulement après que j'ai déplacé le bloc interne à une section différente du code que le problème est apparu (lire : problème pendant la maintenance, pas le développement), et je ne m'y attendais pas.

Sí, si vous ne faites jamais cette erreur alors les compréhensions de listes sont plus élégantes.
Mais par expérience personnelle (et pour avoir vu d'autres personnes faire la même erreur), j'ai vu cela se produire suffisamment de fois pour penser que cela ne vaut pas la peine de souffrir lorsque ces bogues se glissent dans votre code.

Conclusion :

Utilisez map y filter . Ils évitent les bogues subtils et difficiles à diagnostiquer liés à la portée.

Note complémentaire :

N'oubliez pas d'envisager d'utiliser imap y ifilter (en itertools ) si elles sont adaptées à votre situation !

Answer 4

En fait, map et les compréhensions de listes se comportent de manière très différente dans le langage Python 3. Jetez un coup d'œil au programme Python 3 suivant :

def square(x):
    return x*x
squares = map(square, [1, 2, 3])
print(list(squares))
print(list(squares))

On pourrait s'attendre à ce qu'il imprime deux fois la ligne "[1, 4, 9]", mais au lieu de cela, il imprime "[1, 4, 9]" suivi de "[]". La première fois que vous regardez squares il semble se comporter comme une séquence de trois éléments, mais la deuxième fois comme une séquence vide.

Dans le langage Python 2 map retourne une simple liste, comme le font les comprehensions de listes dans les deux langues. L'essentiel est que la valeur de retour de map dans Python 3 (et imap en Python 2) n'est pas une liste - c'est un itérateur !

Les éléments sont consommés lorsque vous itérez sur un itérateur, contrairement à ce qui se passe lorsque vous itérez sur une liste. C'est pourquoi squares semble vide dans le dernier print(list(squares)) ligne.

Pour résumer :

• Lorsque vous traitez avec des itérateurs, vous devez vous rappeler qu'ils ont un état et qu'ils mutent lorsque vous les parcourez.
• Les listes sont plus prévisibles puisqu'elles ne changent que lorsque vous les mutez explicitement ; elles sont conteneurs .
• Et un bonus : les nombres, les chaînes de caractères et les tuples sont encore plus prévisibles car ils ne peuvent pas changer du tout ; ils sont valeurs .

Answer 5

Je trouve que les compréhensions de listes sont généralement plus expressives de ce que j'essaye de faire que map - ils y parviennent tous les deux, mais le premier évite la charge mentale que représente l'effort de compréhension de ce qui pourrait être un problème complexe. lambda expression.

Il y a aussi une interview quelque part (je ne la trouve pas) où Guido énumère les points suivants lambda et les fonctions fonctionnelles comme la chose qu'il regrette le plus d'avoir accepté dans Python, on pourrait donc dire qu'ils ne sont pas pythoniques pour cette raison.