Comprensione elenco vs mappa

C'è un motivo per preferire l'uso della map()comprensione over list o viceversa? Uno dei due è generalmente più efficiente o generalmente considerato più pitonico dell'altro?

mappuò essere microscopicamente più veloce in alcuni casi (quando NON stai realizzando un lambda per lo scopo, ma usando la stessa funzione in map e in un listcomp). La comprensione dell'elenco può essere più rapida in altri casi e la maggior parte (non tutti) dei pitonisti li considera più diretti e chiari.

Un esempio del piccolo vantaggio di velocità della mappa quando si utilizza esattamente la stessa funzione:

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

Un esempio di come il confronto delle prestazioni viene completamente invertito quando la mappa necessita di una lambda:

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

casi

• Caso comune : quasi sempre, vorrai usare una comprensione dell'elenco in Python perché sarà più ovvio quello che stai facendo ai programmatori principianti che leggono il tuo codice. (Questo non si applica ad altre lingue, dove potrebbero essere applicati altri modi di dire.) Sarà persino più ovvio ciò che stai facendo ai programmatori di Python, poiché le comprensioni degli elenchi sono lo standard di fatto in Python per l'iterazione; sono attesi .
• Caso meno comune : tuttavia, se si dispone già di una funzione definita , è spesso ragionevole utilizzarla map, sebbene sia considerata "non pitonica". Ad esempio, map(sum, myLists)è più elegante / conciso di [sum(x) for x in myLists]. Si guadagna l'eleganza di non dover recuperare una variabile dummy (ad esempio, sum(x) for x...o sum(_) for _...o sum(readableName) for readableName...), che è necessario digitare due volte, solo per iterare. Lo stesso argomento vale per filtere reducequalsiasi cosa del itertoolsmodulo: se hai già una funzione a portata di mano, potresti andare avanti e fare un po 'di programmazione funzionale. Ciò aumenta la leggibilità in alcune situazioni e la perde in altre (ad es. Programmatori principianti, argomenti multipli) ... ma la leggibilità del codice dipende in ogni caso dai commenti.
• Quasi mai : potresti voler usare la mapfunzione come una pura funzione astratta mentre esegui una programmazione funzionale, dove stai mappando mapo curry map, o altrimenti trarrai vantaggio dal parlare mapcome una funzione. In Haskell, ad esempio, un'interfaccia di funzione chiamata fmapgeneralizza il mapping su qualsiasi struttura di dati. Questo è molto raro in Python perché la grammatica di Python ti costringe a usare lo stile del generatore per parlare di iterazione; non puoi generalizzare facilmente. (Questo a volte è buono e talvolta cattivo.) Probabilmente puoi trovare rari esempi di pitone dove map(f, *lists)è una cosa ragionevole da fare. L'esempio più vicino che posso trovare sarebbe sumEach = partial(map,sum), che è un one-liner che è molto approssimativamente equivalente a:

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

• Basta usare un for-loop : puoi anche ovviamente usare un for-loop. Sebbene non siano così eleganti dal punto di vista della programmazione funzionale, a volte variabili non locali rendono il codice più chiaro nei linguaggi di programmazione imperativa come Python, perché le persone sono molto abituate a leggere il codice in quel modo. I for-loop sono anche, generalmente, i più efficienti quando stai semplicemente facendo qualsiasi operazione complessa che non sta costruendo un elenco come la comprensione delle liste e la mappa per cui sono ottimizzati (ad esempio sommando o facendo un albero, ecc.) - almeno efficiente in termini di memoria (non necessariamente in termini di tempo, dove mi aspetterei nella peggiore delle ipotesi un fattore costante, salvo qualche raro singhiozzo patologico di raccolta dei rifiuti).

"Pythonism"

Non mi piace la parola "pitone" perché non trovo che pitone sia sempre elegante ai miei occhi. Tuttavia, mape filterfunzioni simili (come il itertoolsmodulo molto utile ) sono probabilmente considerate non ritoniche in termini di stile.

Pigrizia

In termini di efficienza, come la maggior parte dei costrutti di programmazione funzionale, MAP PU BE ESSERE LUSSUOSO , e in effetti è pigro in pitone. Ciò significa che puoi farlo (in python3 ) e il tuo computer non esaurirà la memoria e perderà tutti i tuoi dati non salvati:

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

Prova a farlo con una comprensione dell'elenco:

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

Nota che anche le comprensioni degli elenchi sono intrinsecamente pigre, ma Python ha scelto di implementarle come non pigre . Tuttavia, python supporta la comprensione dell'elenco pigro sotto forma di espressioni generatrici, come segue:

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

Fondamentalmente puoi pensare alla [...]sintassi come passare un'espressione di generatore al costruttore della lista, come list(x for x in range(5)).

Breve esempio inventato

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

Le comprensioni dell'elenco sono non pigre, quindi potrebbe richiedere più memoria (a meno che non si utilizzino le comprensioni del generatore). Le parentesi quadre [...]spesso rendono le cose ovvie, specialmente quando si trovano in un pasticcio di parentesi. D'altra parte, a volte finisci per essere prolisso come scrivere [x for x in.... Finché si mantengono brevi le variabili dell'iteratore, le comprensioni degli elenchi sono generalmente più chiare se non si rientra il codice. Ma puoi sempre indentare il tuo codice.

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

o rompere le cose:

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

Confronto di efficienza per python3

map è ora pigro:

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

Pertanto, se non mapuserete tutti i vostri dati, o non saprete in anticipo di quanti dati avete bisogno, in python3 (ed espressioni del generatore in python2 o python3) eviterete di calcolarne i valori fino all'ultimo momento necessario. Di solito questo supererà di gran lunga qualsiasi sovraccarico dall'uso map. Il rovescio della medaglia è che questo è molto limitato in Python rispetto alla maggior parte dei linguaggi funzionali: ottieni questo vantaggio solo se accedi ai tuoi dati da sinistra a destra "in ordine", perché le espressioni del generatore python possono essere valutate solo nell'ordine x[0], x[1], x[2], ....

Tuttavia, diciamo che abbiamo una funzione pre-creata fche vorremmo mape ignoriamo la pigrizia mapforzando immediatamente la valutazione list(...). Otteniamo risultati molto interessanti:

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

I risultati sono nella forma AAA / BBB / CCC dove A è stato eseguito con una workstation Intel del 2010 circa con Python 3.?.?, E B e C sono stati eseguiti con una workstation AMD del 2013 circa con Python 3.2.1, con hardware estremamente diverso. Il risultato sembra essere che la comprensione di mappe ed elenchi sia paragonabile nelle prestazioni, che è fortemente influenzata da altri fattori casuali. L'unica cosa che possiamo dire sembra essere che, stranamente, mentre ci aspettiamo che la comprensione dell'elenco [...]funzioni meglio delle espressioni del generatore (...), mapè ANCHE più efficiente delle espressioni del generatore (sempre supponendo che tutti i valori vengano valutati / utilizzati).

È importante rendersi conto che questi test assumono una funzione molto semplice (la funzione identità); tuttavia questo va bene perché se la funzione fosse complicata, il sovraccarico delle prestazioni sarebbe trascurabile rispetto ad altri fattori nel programma. (Potrebbe essere comunque interessante testare con altre cose semplici come f=lambda x:x+x)

Se sei abile a leggere l'assembly di Python, puoi usare il dismodulo per vedere se è proprio quello che succede dietro le quinte:

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

Sembra che sia meglio usare la [...]sintassi di list(...). Purtroppo la mapclasse è un po 'opaca da disassemblare, ma possiamo farcela con il nostro test di velocità.

Python 2: dovresti usare mape filterinvece della comprensione dell'elenco.

Un motivo oggettivo per cui dovresti preferirli anche se non sono "Pythonic" è questo:
richiedono funzioni / lambdas come argomenti, che introducono un nuovo ambito .

Sono stato morso da questo più di una volta:

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

ma se invece avessi detto:

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

allora tutto sarebbe andato bene.

Si potrebbe dire che ero sciocco per aver usato lo stesso nome di variabile nello stesso ambito.

Non lo ero. Inizialmente il codice andava bene, i due xnon erano nello stesso ambito.
È stato solo dopo che mi sono trasferito il blocco interno in un'altra sezione del codice è emerso il problema (leggi: problema durante la manutenzione, non in fase di sviluppo) e non me lo aspettavo.

Sì, se non commetti questo errore, la comprensione delle liste è più elegante.
Ma per esperienza personale (e dal vedere gli altri commettere lo stesso errore) l'ho visto accadere abbastanza volte che penso che non valga la pena soffrire quando questi bug si insinuano nel tuo codice.

Conclusione:

Usa mape filter. Impediscono bug impercettibili e difficili da diagnosticare.

Nota a margine:

Non dimenticare di considerare l'utilizzo imape ifilter(in itertools) se sono appropriati per la tua situazione!

In realtà, la mapcomprensione dell'elenco si comporta in modo abbastanza diverso nel linguaggio Python 3. Dai un'occhiata al seguente programma Python 3:

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

Potresti aspettarti che stampi la riga "[1, 4, 9]" due volte, ma invece stampa "[1, 4, 9]" seguito da "[]". La prima volta che lo guardi squaressembra comportarsi come una sequenza di tre elementi, ma la seconda volta come uno vuoto.

Nel linguaggio Python 2 maprestituisce un vecchio elenco semplice, proprio come fanno le comprensioni degli elenchi in entrambe le lingue. Il punto cruciale è che il valore restituito mapin Python 3 (e imapin Python 2) non è un elenco - è un iteratore!

Gli elementi vengono consumati quando si scorre su un iteratore, diversamente da quando si scorre su un elenco. Questo è il motivo per cui squaresappare vuoto nell'ultima print(list(squares))riga.

Riassumere:

• Quando hai a che fare con gli iteratori devi ricordare che sono statali e che mutano mentre li attraversi.
• Gli elenchi sono più prevedibili poiché cambiano solo quando li muthi esplicitamente; sono contenitori .
• E un vantaggio: numeri, stringhe e tuple sono ancora più prevedibili poiché non possono cambiare affatto; sono valori .

Trovo che le comprensioni degli elenchi siano generalmente più espressive di ciò che sto cercando di fare rispetto a map- entrambi lo fanno, ma il primo salva il carico mentale di cercare di capire quale potrebbe essere lambdaun'espressione complessa .

C'è anche un'intervista là fuori da qualche parte (non riesco a trovarla in maniera sprovvista) in cui Guido elenca lambdale funzioni funzionali come la cosa di cui più si rammarica di accettare in Python, quindi potresti argomentare che sono non-Pythonic in virtù di quella.

Ecco un possibile caso:

map(lambda op1,op2: op1*op2, list1, list2)

contro:

[op1*op2 for op1,op2 in zip(list1,list2)]

Immagino che zip () sia uno svantaggio sfortunato e inutile che devi indulgere se insisti nell'usare la comprensione dell'elenco anziché la mappa. Sarebbe bello se qualcuno chiarisse questo in modo affermativo o negativo.

Se hai intenzione di scrivere un codice asincrono, parallelo o distribuito, probabilmente preferirai mapuna comprensione dell'elenco - poiché la maggior parte dei pacchetti asincroni, paralleli o distribuiti fornisce una mapfunzione per sovraccaricare Python map. Quindi passando la mapfunzione appropriata al resto del codice, potrebbe non essere necessario modificare il codice seriale originale per farlo funzionare in parallelo (ecc.).

Quindi, dato che Python 3 map()è un iteratore, devi tenere a mente ciò di cui hai bisogno: un iteratore o un listoggetto.

Come già accennato @AlexMartelli , map()è più veloce della comprensione dell'elenco solo se non si utilizza la lambdafunzione.

Ti presenterò alcuni paragoni di tempo.

_{Python 3.5.2 e CPython
ho usato il taccuino di Giove e in particolare il %timeitcomando magico incorporato
Misure : s == 1000 ms == 1000 * 1000 µs = 1000 * 1000 * 1000 ns}

Impostare:

x_list = [(i, i+1, i+2, i*2, i-9) for i in range(1000)]
i_list = list(range(1000))

Funzione integrata:

%timeit map(sum, x_list)  # creating iterator object
# Output: The slowest run took 9.91 times longer than the fastest. 
# This could mean that an intermediate result is being cached.
# 1000000 loops, best of 3: 277 ns per loop

%timeit list(map(sum, x_list))  # creating list with map
# Output: 1000 loops, best of 3: 214 µs per loop

%timeit [sum(x) for x in x_list]  # creating list with list comprehension
# Output: 1000 loops, best of 3: 290 µs per loop

lambda funzione:

%timeit map(lambda i: i+1, i_list)
# Output: The slowest run took 8.64 times longer than the fastest. 
# This could mean that an intermediate result is being cached.
# 1000000 loops, best of 3: 325 ns per loop

%timeit list(map(lambda i: i+1, i_list))
# Output: 1000 loops, best of 3: 183 µs per loop

%timeit [i+1 for i in i_list]
# Output: 10000 loops, best of 3: 84.2 µs per loop

Esiste anche un'espressione del generatore, vedi PEP-0289 . Quindi ho pensato che sarebbe stato utile aggiungerlo al confronto

%timeit (sum(i) for i in x_list)
# Output: The slowest run took 6.66 times longer than the fastest. 
# This could mean that an intermediate result is being cached.
# 1000000 loops, best of 3: 495 ns per loop

%timeit list((sum(x) for x in x_list))
# Output: 1000 loops, best of 3: 319 µs per loop

%timeit (i+1 for i in i_list)
# Output: The slowest run took 6.83 times longer than the fastest. 
# This could mean that an intermediate result is being cached.
# 1000000 loops, best of 3: 506 ns per loop

%timeit list((i+1 for i in i_list))
# Output: 10000 loops, best of 3: 125 µs per loop

Hai bisogno di un listoggetto:

Usa la comprensione dell'elenco se è una funzione personalizzata, usa list(map())se c'è una funzione integrata

Non hai bisogno di listoggetti, hai solo bisogno di uno iterabile:

Usa sempre map()!

Ho eseguito un test rapido confrontando tre metodi per invocare il metodo di un oggetto. La differenza di tempo, in questo caso, è trascurabile ed è una questione della funzione in questione (vedere la risposta di @Alex Martelli ). Qui, ho esaminato i seguenti metodi:

# map_lambda
list(map(lambda x: x.add(), vals))

# map_operator
from operator import methodcaller
list(map(methodcaller("add"), vals))

# map_comprehension
[x.add() for x in vals]

Ho esaminato gli elenchi (memorizzati nella variabile vals) di numeri interi (Python int) e in virgola mobile (Python float) per aumentare le dimensioni dell'elenco. È considerata la seguente classe fittizia DummyNum:

class DummyNum(object):
    """Dummy class"""
    __slots__ = 'n',

    def __init__(self, n):
        self.n = n

    def add(self):
        self.n += 5

In particolare, il addmetodo. L' __slots__attributo è una semplice ottimizzazione in Python per definire la memoria totale richiesta dalla classe (attributi), riducendo la dimensione della memoria. Ecco i grafici risultanti.

Come affermato in precedenza, la tecnica utilizzata fa una differenza minima e dovresti codificare in un modo che sia più leggibile per te o nella circostanza particolare. In questo caso, la comprensione dell'elenco ( map_comprehensiontecnica) è più rapida per entrambi i tipi di aggiunte in un oggetto, in particolare con elenchi più brevi.

Visita questo pastebin per la fonte utilizzata per generare la trama e i dati.

Ritengo che il modo più Pythonic sia usare una comprensione della lista invece di mape filter. Il motivo è che la comprensione dell'elenco è più chiara di mape filter.

In [1]: odd_cubes = [x ** 3 for x in range(10) if x % 2 == 1] # using a list comprehension

In [2]: odd_cubes_alt = list(map(lambda x: x ** 3, filter(lambda x: x % 2 == 1, range(10)))) # using map and filter

In [3]: odd_cubes == odd_cubes_alt
Out[3]: True

Come vedi, una comprensione non richiede lambdaespressioni extra come mapnecessità. Inoltre, una comprensione consente anche di filtrare facilmente, mentre maprichiede filterdi consentire il filtraggio.

Ho provato il codice di @ alex-martelli ma ho riscontrato alcune discrepanze

python -mtimeit -s "xs=range(123456)" "map(hex, xs)"
1000000 loops, best of 5: 218 nsec per loop
python -mtimeit -s "xs=range(123456)" "[hex(x) for x in xs]"
10 loops, best of 5: 19.4 msec per loop

map impiega lo stesso tempo anche per intervalli molto ampi, mentre l'utilizzo della comprensione dell'elenco richiede molto tempo, come è evidente dal mio codice. Quindi, a parte il fatto di essere considerato "non pitonico", non ho affrontato alcun problema di prestazioni relativo all'utilizzo della mappa.