A common Python myth, or why you don’t need map, filter, and reduce in Python

Florian Huber
3 min readJan 25, 2024

--

I very frequently teach Python. A lot. I teach Python to bachelor students, to master students, to researchers. And every standard Python course has to cover the Python elements map(), filter() and reduce().

Many programmers apparently love them. They are described as cornerstones of a certain style of programming (functional programming) and the same three elements can therefore also be found in many other programming languages such as Java, C# and many others.

This alone is a good-enough reason to learn a bit about these three elements. But I see my job here in taking a different view.

When it comes to Python the high appreciation for these three elements is by far greater in people which transition to Python from such other languages. People for whom Python is their main programming language, show much less appreciation in my experience. Same for me.

I have realized many projects with Python over the years, and released several software packages. Guess how often I used map(), filter() and reduce() in any line of code I added to those projects? The answer is: ZERO. Not a single case.

But that’s just me. Maybe I am simply a bad programmer.

Then again, I also work in many projects with other people’s code. I occasionally see a map() here and there, maybe I saw a reduce() function some time ago… but really not that often!

Let’s make this short. Here are my reasons for why I think that those three elements are often over-rated in Python.

1They are not faster!
A common myth you will read many times in diverse tutorials and blog posts is:

“map, filter, reduce are much faster than for-loops”

This is often explained by the fact that they are all “written in C”.

This is two times wrong.
First of all, the explanation is wrong. 99% of all Python users work with CPython which only means that the interpreter that runs our Python code, is written in C. Not only map(), filter(), reduce(), but all of it.
And second, it simply is not true. There is usually no notable speed gain*. See for instance the example below showing three ways to implement the same thing in Python. First with an explicit for-loop, then with map(), and finally with a list comprehension. Each time you measure such a code execution run times will vary a bit. But in essence we can say that they are equally fast (or rather, since it’s pure Python: slow).

2 It won’t help to make your code readable!
Every programmer has a different view on what she/he thinks is well-readable, clean code. I, for instance, have worked so much with Python that the 3rd option in the example above (the list comprehension) is the most accessible option to me. If it is option 1 or 2 for you, fine as well. I would generally consider all three options to be on the same level of readability and best practices. At this point it is nothing more than a question of personal preferences and style.

Conclusion

If you are learning how to program with Python, you should at some point become able to read and understand code that uses map(), filter() and reduce(). But, anything more than that is purely optional and up to you. There is nothing in Python that you can only do by using those elements. And if you hope for faster programs, better look elsewhere**.

*I know: you can execute the Python map() very quickly at first. Most of the computation time is only used when we actually — as in my example- execute the function, for instance when we call list(map(...)). I am sure there are several good use cases for this. But usually I found better, more efficient solutions than using map() for those cases, too.
**If you really want to speed up code, this is not the way to go. Try using efficient Python libraries such as Numpy, Pandas, Scikit-Learn, Pytorch etc. And/or, compile you code using Numba. And/or try to parallelize your code, e.g. using Numba or Dask.

--

--

Florian Huber

Professor for Data Science at University of Applied Sciences Düsseldorf | research software engineer | former biological physicist | former chocolatier |