случаи
- Типичный случай : почти всегда вы захотите использовать списочное понимание в python, потому что это будет более очевидно, что вы делаете для начинающих программистов, читающих ваш код. (Это не относится к другим языкам, где могут применяться другие идиомы.) Будет даже более очевидно, что вы делаете с программистами на python, поскольку списочные выражения являются фактическим стандартом в python для итерации; они ожидаются .
- Менее распространенный случай : однако, если у вас уже есть определенная функция , ее часто целесообразно использовать
map, хотя она считается «непифонной». Например, map(sum, myLists)более элегантно / кратко, чем [sum(x) for x in myLists]. Вы получаете элегантность того, что вам не нужно составлять фиктивную переменную (например, sum(x) for x...или sum(_) for _...или sum(readableName) for readableName...), которую нужно вводить дважды, просто для итерации. Тот же аргумент справедлив для filterи reduceи всего из itertoolsмодуля: если у вас уже есть удобная функция, вы можете пойти дальше и заняться функциональным программированием. Это дает читабельность в некоторых ситуациях и теряет ее в других (например, начинающие программисты, несколько аргументов) ... но читаемость вашего кода в любом случае сильно зависит от ваших комментариев.
- Почти никогда : вы можете захотеть использовать
mapфункцию как чистую абстрактную функцию во время выполнения функционального программирования, когда вы отображаете mapили каррируете map, или иным образом извлекаете пользу из разговора mapкак функции. Например, в Haskell интерфейс с функтором fmapобобщает отображение по любой структуре данных. Это очень редко встречается в python, потому что грамматика python заставляет вас использовать генераторный стиль, чтобы говорить об итерации; Вы не можете легко обобщить это. (Это иногда хорошо, а иногда плохо.) Вероятно, вы можете придумать редкие примеры на python, в которых map(f, *lists)есть смысл. Самый близкий пример, который я могу придумать, был бы sumEach = partial(map,sum), который является однострочным, который очень приблизительно эквивалентен:
def sumEach(myLists):
return [sum(_) for _ in myLists]
- Просто используя
for-loop : Вы также можете просто использовать цикл for. Хотя это не так элегантно с точки зрения функционального программирования, иногда нелокальные переменные делают код более понятным в императивных языках программирования, таких как python, потому что люди очень привыкли читать код таким образом. Циклы for также, как правило, наиболее эффективны, когда вы просто выполняете какую-либо сложную операцию, которая не строит список, например, списки и карты оптимизированы (например, суммирование, создание дерева и т. Д.) - по крайней мере эффективный с точки зрения памяти (не обязательно с точки зрения времени, где я бы в худшем случае ожидал постоянного фактора, за исключением некоторого редкого патологического сбоя при сборке мусора).
"Pythonism"
Мне не нравится слово «pythonic», потому что я не считаю, что pythonic всегда элегантен в моих глазах. Тем не менее, mapи filterи подобные функции (например, очень полезный itertoolsмодуль), вероятно, считаются непифоническими с точки зрения стиля.
Лень
С точки зрения эффективности, как и большинство функциональных программных конструкций, MAP МОЖЕТ БЫТЬ ЛЕННЫМ , и на самом деле ленив в Python. Это означает, что вы можете сделать это (в python3 ), и ваш компьютер не исчерпает память и потеряет все ваши несохраненные данные:
>>> map(str, range(10**100))
<map object at 0x2201d50>
Попробуйте сделать это с пониманием списка:
>>> [str(n) for n in range(10**100)]
# DO NOT TRY THIS AT HOME OR YOU WILL BE SAD #
Обращаем ваше внимание, что списочные выражения также по своей природе ленивы, но python решил реализовать их как не ленивые . Тем не менее, Python поддерживает ленивые списки в форме выражений генератора, как показано ниже:
>>> (str(n) for n in range(10**100))
<generator object <genexpr> at 0xacbdef>
Вы можете в основном думать о [...]синтаксисе как о передаче выражения генератора в конструктор списка, например list(x for x in range(5)).
Краткий надуманный пример
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))})
Понимания списков не ленивы, поэтому могут потребовать больше памяти (если вы не используете генератор пониманий). Квадратные скобки [...]часто делают вещи очевидными, особенно когда в беспорядке скобок. С другой стороны, иногда вы становитесь многословным, как печатать [x for x in.... До тех пор, пока вы сохраняете свои переменные итератора короткими, списки обычно более понятны, если вы не делаете отступ в коде. Но вы всегда можете сделать отступ для своего кода.
print(
{x:x**2 for x in (-y for y in range(5))}
)
или разбить вещи:
rangeNeg5 = (-y for y in range(5))
print(
{x:x**2 for x in rangeNeg5}
)
Сравнение эффективности для python3
map сейчас лень
% python3 -mtimeit -s 'xs=range(1000)' 'f=lambda x:x' 'z=map(f,xs)'
1000000 loops, best of 3: 0.336 usec per loop ^^^^^^^^^
Поэтому, если вы не будете использовать все свои данные или заранее не знаете, сколько данных вам нужно, mapв python3 (и в выражениях генератора в python2 или python3) не будет вычисляться их значение до последнего необходимого момента. Обычно это перевешивает любые накладные расходы от использования map. Недостатком является то, что в python это очень ограничено по сравнению с большинством функциональных языков: вы получаете это преимущество, только если обращаетесь к своим данным слева направо «по порядку», потому что выражения генератора питона могут оцениваться только в порядке x[0], x[1], x[2], ....
Однако предположим, что у нас есть готовая функция, которую fмы хотели бы выполнять map, и мы игнорируем лень map, немедленно форсируя оценку list(...). Мы получаем очень интересные результаты:
% 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>)
Результаты представлены в виде AAA / BBB / CCC, где A был выполнен на рабочей станции Intel около 2010 года с python 3.?.?, А B и C были выполнены на рабочей станции AMD около 2013 года с python 3.2.1, с совершенно другим оборудованием. В результате получается, что представления карт и списков сопоставимы по производительности, что сильнее всего зависит от других случайных факторов. Единственное, что мы можем сказать, это то, что, как ни странно, хотя мы ожидаем, что понимание списка [...]будет работать лучше, чем выражения генератора (...), mapТАКЖЕ более эффективно, чем выражения генератора (опять же, предполагая, что все значения вычисляются / используются).
Важно понимать, что эти тесты предполагают очень простую функцию (тождественную функцию); однако это хорошо, потому что если бы функция была сложной, то потери производительности были бы незначительными по сравнению с другими факторами в программе. (Это может все еще быть интересно проверить с другими простыми вещами как f=lambda x:x+x)
Если вы хорошо разбираетесь в сборке Python, вы можете использовать disмодуль, чтобы увидеть, действительно ли это происходит за кулисами:
>>> 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
Кажется, лучше использовать [...]синтаксис, чем list(...). К сожалению, mapкласс немного непрозрачен для разборки, но мы можем сделать это с нашим тестом скорости.
