Python's (Weak) Functional Programming Paradigm

by Jeremy Jones

Python is not an FP language. It may have a quasi-FP construct here or there, but it is not FP.

So what? Python's focus is not to be a pure anything language. Some would say that it isn't pure object oriented, and they're right, depending on whose definition of OO they use. It isn't a pure imperative language, either, although it supports that model of programming pretty well. And to the lack of a pure OO or imperative style, I add another, "so what?"

Python has been heading away from a traditional FP model for some time now. The beginning of the shift probably occurred in Python 2.0 with the introduction of list comprehensions. In addition, PEP 3000 plans to cut some specific FP constructs such as the lambda statement and the map(), filter(), and reduce() functions.

Rather than adhering to a particular model of programming for its own sake, Python's focus is to be a language that works. It doesn't attempt to raise up any one programming paradigm as a shibboleth. It strives to be usable.

Removing the constructs mentioned above is a good example of this. Python programmers will use list comprehensions in place of some of the former, explicit FP constructs after they are removed from the language. When list comprehensions first came out, I didn't begin using them right away. I still found myself doing map(lambda x: x * 2, some_list) rather than [x * 2 for x in some_list]. Granted, this is an extremely simple example, but the map(lambda) construct feels terribly odd now. The list comprehension feels more natural. I'm sure others will feel the opposite about this, but the list comprehension is more linearly readable.

Guido, and I'm sure others, feel that the language will be more usable when some of these constructs are gone from the language. Maybe it isn't totally about these constructs themselves being less usable than other constructs. Maybe it has something to do with a consistency within the language and some of these constructs just don't fit. Whether the motivation is about the constructs themselves or an overall language cohesion, I believe the language will benefit from their removal.

In a way, even though I enjoy the FP model, I'm glad that Python is making a shift away from FP in favor of a more pragmatic Python. When religious issues become paramount to the Python community in general, and to the maintainers specifically, I will continue my programming pilgrimage with another language.


2005-10-21 11:15:23
Just a observation
List comprehensions was "borrowed" from Haskell, a functional language. We are only switching syntax really.

Currently there are 4 ways of processing lists.
Assuming you will access the results sequentially (e.g. a for loop)your example could be written as:

map(lambda x: x * 2, some_list)
itertools.imap(lambda x: x * 2, some_list)
[x * 2 for x in some_list]
(x * 2 for x in some_list)

I think the proposed change has more to do with the basic philosophy of Python of "there should be only one way to do it" and to go for the clearest readable syntax of any given idiom even if this means having to introduce some new stuff.