[bunderbunder]

There has been some pushback on the inclusion of common functional idioms in Python, though. For example, GvR has expressed regret about allowing map, filter, etc. into Python, on the grounds that comprehensions are a more Pythonic way to accomplish most of the same stuff.

[metalliqaz]

I assume it's because of this...

Zen of Python: There should be one-- and preferably only one --obvious way to do it.

[bunderbunder]

True, but, if it were just that, I would expect Python to only have the map, filter, etc. functions, which have been in there since 1.0. List comprehensions were introduced much later, in version 2.

That makes comprehensions the 2nd way to do it. They're also less obvious in my book, since their readability tends to drop precipitously once you start adding multiple "for" clauses to one.

[somenewacc]

But comprehensions are also a functional idiom.

[bunderbunder]

Yeah, sorry, I didn't mean to say that Python's not functional without a "map" function. More trying to guess where that perception comes from. Python's comprehensions are (I believe) inspired by Haskell, but, if you're not a Haskeller, you're probably more used to other ways of doing things.

[lmm]

The version Python has is awkward to work with, to the point that many Haskell programmers don't even realise it exists. The "do notation" style is much clearer than the "comprehension" style; unfortunately Python has no equivalent.

[bad_user]

FP means referential transparency. For-comprehensions operate on iterators and iterators are not FP, being a very dirty and mutable protocol.

Do not confuse FP with declarative programming or with laziness. FP often implies declarative APIs and laziness but not vice-versa.

[duckerude]

Python's comprehensions were lifted from Haskell, and its map and filter functions also operate on iterables. They can't be purely functional because of the surrounding language, but they do follow a functional style.

(expr for item in iterable if cond) is more or less another way to spell map(lambda item: expr, filter(lambda item: cond, iterable)), except readable.

You could define "functional programming" to absolutely require referential transparency, but that's not what the rest of the thread is doing.

[kthielen]

I don't mean to be pedantic but IIRC Python's comprehensions actually came from the SETL language.

Obviously it's ultimately the same thing either way, but that's the lineage (SETL -> ABC -> Python).

https://en.wikipedia.org/wiki/SETL

[duckerude]

I didn't know about SETL, that's interesting.

https://docs.python.org/3/howto/functional.html#generator-ex... claims Python borrowed them from Haskell, but the ABC link seems more likely.

[zephyrfalcon]

ABC didn't have list comprehensions though, in spite of being influenced by SETL.

As I recall, Python did get them from Haskell, which in turn got them from Miranda, which got them from KRC. Before that it gets fuzzy, but it's likely that SETL was eventually at the root of it.

[bluecalm]

Aren't map and filter just redundant if you accept list comprehension as Pythonic thing to do?

[jrs95]

Maybe just map and filter but there are far more operations that can be done on these types than what is cleanly expressed in a comprehension.