It's actually a bit amusing to see The Standard Reasons given for the desirability of functional programming when they really don't particularly apply to Python functional programming.
(To the extent that "modularity" and "composition" apply to Python functional programming, they aren't really all that much better than the usual Python tools, used properly, and to the extent that they are it is because they fit into the OO rather than the other way around. Python is an OO language with functional things appended as useful. This is not a bad thing, but it doesn't make it a functional language.)
Python is multi-paradigm; it's not dominantly OO. Comparing python libraries to java libraries, functional composition is used just as frequently as OO composition (if not more so).
If you're building a website, in Python/Django, you pass in your request handler function using first class functions. In java, you inherit from the request handler class, and override the method.
JsonTools loads and dumps are pure functions. In java, josn.org, there's a class for each JSON type that you interact with.
That being said, I can also think of many Python libraries that use classes.
Functions are objects in Python. Thanks to __call__, quite profoundly so.
Multiparadigm is a bit oversold; in any language, when paradigms conflict, something wins. Either you consistently choose something, in which case you get a coherent language, or you don't, in which case you get an incoherent mismash (which may be usable, but tends to scale poorly in the end). In Python, that something is OO.
OO broadly means the base abstraction of the language syntax and base libraries is classes and objects. That's Python. Everything is an object, even when that's papered over with things that don't wave it in your face.
Lisp, C++, and Python are multi-paradigm; you can write programs or libraries that are largely procedural, object-oriented, or functional in all of these languages.
No. Just... No. Python is an object-oriented imperative language. Sure, it allows you to do some functional-esque things, but it's at best a "functional-lite" language.
Plus, I wouldn't say that lisp fits into any paradigm. Better to say that it transcends paradigms.
How about we all just admit that "OO" has multiple meanings?
There is OO as a style of software design: we give data the responsibility for providing an interface, which is encapsulated with the data. And the same interface can be used for multiple types of data, thus freeing code from needing to know what type of data it is dealing with.
Python can be used in this style, but it doesn't have to be. I've done plenty of Python programming without using it. And, although no one calls C an OO language, you can program this way in C, if you want. It's painful, but not impossible.
OTOH, there is "OO" as language features, usually mechanisms for encapsulation & instantiation, with some kind of dynamic binding capability, such as Python's classes/objects.
In that sense, I agree with you: Python is an OO language. On the other hand, in the first sense, I agree with the article author: Python supports OO programming, and it also supports programming in other paradigms.
First, because Python's iterators are a way of forming a wrapper around an arbitrary data set. This is in contrast to (say) C++ iterators, which are merely pointers into a data set, and so it takes two of them to specify a range of data.
Second, Python's "for" construction, along with imap and other such things, mean that we can program with iterators, without treating them as mutable objects; they merely wrap the data returned by some computation.
Third, Python's iterators have no write capability. Again, contrast this with C++, where output iterators are the usual way to answer the question, "What do I do with this data?"
Add Python's "yield" to the mix, and the result is a very natural, efficient way for a function that computes a large data set, to return the entire set (functional style), rather than writing it somewhere (very non-functional).
It's actually a bit amusing to see The Standard Reasons given for the desirability of functional programming when they really don't particularly apply to Python functional programming.
(To the extent that "modularity" and "composition" apply to Python functional programming, they aren't really all that much better than the usual Python tools, used properly, and to the extent that they are it is because they fit into the OO rather than the other way around. Python is an OO language with functional things appended as useful. This is not a bad thing, but it doesn't make it a functional language.)