Почему Python не очень хорош для функционального программирования? [закрытый]
Чтобы быть действительно эквивалентным imap, используйте выражение генератора:
(x + 3 for x in mylist)
Как и imap, это не сразу создает полный новый список, а вместо этого вычисляет элементы результирующей последовательности по требованию (и, следовательно, намного эффективнее, чем понимание списка, если вы объединяете результат в другую итерацию).
Если вам интересно, где partial был бы лучшим вариантом, чем lambda в реальном мире, это может быть, когда вы имеете дело с переменным числом аргументов:
>>> from functools import partial
>>> def a(*args):
... return sum(args)
...
>>> b = partial(a, 2, 3)
>>> b(6, 7, 8)
26
Эквивалентная версия с использованием lambda будет ...
>>> b = lambda *args: a(2, 3, *args)
>>> b(6, 7, 8)
26
, который немного менее лаконичен, но lambda дает вам возможность применения вне порядка, что partial не делает:
>>> def a(x, y, z):
... return x + y - z
...
>>> b = lambda m, n: a(m, 1, n)
>>> b(2, 5)
-2
6 ответов
Вопрос, на который вы ссылаетесь, спрашивает, какие языки поддерживают как объектно-ориентированное, так и функциональное программирование. Python не продвигает функциональное программирование, хотя он работает достаточно хорошо.
Лучший аргумент против функционального программирования на Python заключается в том, что императивные / объектно-ориентированные варианты использования являются Гвидо внимательно рассмотрел, а варианты использования функционального программирования - нет. Когда я пишу императивный Python, это один из самых красивых языков, которые я знаю. Когда я пишу функциональный Python, он становится таким же уродливым и неприятным, как и ваш средний язык, у которого нет BDFL .
Это не значит, что он плохой, просто вам нужно работать больше, чем вы бы сделали это, если бы перешли на язык, который продвигает функциональное программирование, или перешли на написание OO Python.
Вот функциональные вещи, которые мне не хватает в Python:
- Сопоставление с образцом
- Хвостовая рекурсия
- Большая библиотека функций со списком
- Класс функционального словаря
- Автоматическое каррирование
- Краткий способ составления функций
- Ленивые списки
- Простой и мощный синтаксис выражений (простой блочный синтаксис Python не позволяет Гвидо добавлять его)
- Отсутствие сопоставления с образцом и хвостовой рекурсии означает, что ваши базовые алгоритмы должны быть написаны императивно. Рекурсия в Python уродлива и медленна.
- Небольшая библиотека списков и отсутствие функциональных словарей означают, что вам придется писать много вещей самостоятельно.
- Отсутствие синтаксиса для каррирования или композиции означает, что стиль без точек содержит столько же знаков препинания, как и явная передача аргументов.
- Итераторы вместо ленивых списков означают, что вы должны знать, хотите ли вы эффективности или постоянства, и рассыпать вызовы в
список, если вы хотите постоянства. (Итераторы используются один раз) - Простой императивный синтаксис Python вместе с его простым анализатором LL1 означает, что лучший синтаксис для if-выражений и лямбда-выражений в принципе невозможен. Гвидо это нравится, и я думаю, он прав.
Гвидо дает хорошее объяснение здесь . Вот самая важная часть:
Я никогда не считал Python сильно зависит от функциональных языки, что бы ни говорили люди или подумайте. Я был намного более знакомым с императивными языками, такими как C и Алгол 68, и хотя я сделал функции первоклассные объекты, я не рассматривал Python как функционал язык программирования. Однако раньше было ясно, что пользователи хотели делать гораздо больше со списками и функциями.
...
Также стоит отметить, что даже хотя я не представлял Python как функциональный язык, введение закрытий был полезен в разработка многих других передовых особенности программирования. Например, определенные аспекты классов нового стиля, декораторы и другие современные функции полагаться на эту способность.
Наконец, даже несмотря на то, что ряд функции функционального программирования имеют был представлен на протяжении многих лет, Python по-прежнему не хватает некоторых функций, имеющихся в «Настоящее» функциональное программирование языков. Например, Python делает не выполнять определенные виды оптимизации (например, хвостовая рекурсия). В общем, поскольку Python чрезвычайно динамичный характер, это невозможно сделать вид оптимизации во время компиляции известно из функциональных языков, таких как Haskell или ML. И это нормально.
Я извлекаю из этого две вещи:
- Создатель языка на самом деле не считает Python функциональным языком. Следовательно, можно увидеть «функциональные» функции, но вы вряд ли увидите что-либо, что окончательно функционально.
- Динамический характер Python препятствует некоторым оптимизациям, которые вы видите в других функциональных языках. Конечно, Lisp столь же динамичен (если не более динамичен), что и Python, так что это лишь частичное объяснение.
Схема не имеет алгебраических типов данных или сопоставления с образцом, но это определенно функциональный язык. Раздражающие вещи о Python с точки зрения функционального программирования:
Crippled Lambdas. Поскольку Lambdas может содержать только выражение, и вы не можете делать все так же просто в контексте выражения, это означает, что функции, которые вы можете определять «на лету», ограничены.
If - это операторы, а не выражения. Это означает, среди прочего, что у вас не может быть лямбда с If внутри. (Это исправлено тернариями в Python 2.5, но выглядит некрасиво.)
Гвидо угрожает удалять карту, фильтровать и сокращать время от времени
С другой стороны, в python есть лексические замыкания, лямбды и понимание списков (которые на самом деле являются "функциональными" концепция независимо от того, признает ли это Гвидо). Я много занимаюсь программированием в "функциональном стиле" на Python, но вряд ли могу сказать, что это идеально.
Я бы никогда не назвал Python «функциональным», но всякий раз, когда я программирую на Python, код неизменно оказывается почти полностью функциональным.
По общему признанию, это в основном из-за чрезвычайно хорошего понимания списка. Так что я не обязательно предлагаю Python в качестве языка функционального программирования, но я предлагаю функциональное программирование для всех, кто использует Python.
Позвольте мне продемонстрировать с помощью фрагмента кода, взятого из ответа на "функциональный" вопрос Python по SO
Python:
def grandKids(generation, kidsFunc, val):
layer = [val]
for i in xrange(generation):
layer = itertools.chain.from_iterable(itertools.imap(kidsFunc, layer))
return layer
Haskell:
grandKids generation kidsFunc val =
iterate (concatMap kidsFunc) [val] !! generation
Основное отличие заключается в том, что стандартная библиотека Haskell имеет полезные функции для функционального программирования: в данном случае iterate , concat и ( !!)
Python - почти функциональный язык. Это «функциональный лайт».
Он имеет дополнительные функции, поэтому для некоторых он недостаточно чист.
В нем также отсутствуют некоторые функции, поэтому для некоторых он недостаточен.
Недостающие функции относительно легко записать. Посмотрите сообщения вроде this о FP на Python.