Anything remotely interesting like that is dumped in itertools.
Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known.
Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added built-in sum() at the same time we demoted reduce() from a built-in to something in functools (which is a dumping ground for stuff I don't really care about :-)."
> "I value readability and usefulness for real code"
Amen.
There are plenty of languages where your code ends up looking like an entry in an obfuscation competition without even trying. If you're using Python, and working for me, I expect the code to be readable by anyone.
And, no, I don't give a toss whether the code is three times the length it might have been if it was dangerously, and expensively, obscure.
Quite often, chains of map/filter/reduce/whatever are more readable because you can see the flow of data, like you were looking at a factory production line. List comprehensions and traditional prefix functions (e.g. map(iterable, function)) completely break the visual chain that makes basic functional code so readable.
Like, which of these make more sense?
strList.filter(isNumeric).map(parseInt).filter(x => x != 0)
[ x for x in [ parseInt(s) for s in strList if isNumeric(s) ] if x != 0]
filter(map(filter(strList, isNumeric), parseInt), lambda x: x != 0)
And it's not like Python doesn't have the language features to implement the first pattern. Map,reduce,filter,etc. could simply be added to the iterable base class and be automatically usable for all lists, generators and more.
if you come from a imperative background and everyone is used to working in imperative languages... I guess thats anyone.
Someone coming from, say ruby, or javascript would find list comprehension jarring. You can't compose them and you basically have to rewrite them when its time to extend them.
Yes, lots of them are available. But I also would like to be able to call .sum() on my iterable at the end of a chain, instead of having to mentally unwrap sum(map(filter(filter(map(...))))
But you only ever need to unwrap one sum(). And with sequence comprehensions, what you get instead is sum(... for ... if ... for ... if ...) - I don't think that's improved by rewriting it as (...).sum().
FWIW Python was fourteen years old when GVR joined the Borg. That doesn't address how popular it was but I think it's reasonable to say it was well established.
Guido van Rossum doesn't appreciate FP and he really genuinely doesn't understand it. That's not to say he's dumb or not a nice guy or anything. It's just not his area. And this is reflected in the language.
His attitude of you have to be "really smart" to understand FP is a mistake.
Also definitely learn about using sum on non-numbers, and the key argument to min and max. They can be incredibly handy, but I hardly see them used. Have a contrived example:
Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known.
Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added built-in sum() at the same time we demoted reduce() from a built-in to something in functools (which is a dumping ground for stuff I don't really care about :-)."