I tend to pick up bad memes like crazy. One I picked up some decades ago is that FP has a useful property in this context: it preserves parallelism to remarkably late in the code, such that you can safely understand the impact of async applied to your code.
The lack of first class FP, beyond the type checking stuff, may actually at root be part of the problem: if Python had somehow become the FP rich language it said "nope, different model" -then parallelism and GIL would be a totally different argument.
Maybe I was mis-informed. FP interests me but I am not rich in experience. Maybe its an oversold idea?
I think list comprehensions (and generator expressions) already do (or did, in the past?) classify as FP.
In this context it seems a bit misleading to care about function call overhead (except for TCO) because Python is so slow overall. I'm usually seeing 30x when translating to C. (For pure Python of course, not PyPy or code making good use of numpy.)
Python has FP elements, such as the list comprehensions you mention, but overall I wouldn’t say it’s an FP language.
To continue that example, Python list comprehensions are not very powerful compared to that feature in FP languages, since Python is not expression orientated.
I would classify Python as imperative with FP and OOP elements.
Python is of course a slow language. My point is that writing in a functional style will give you slow code even by Python standards! Good FP languages assume you will write in that style and optimise for that use-case.
The lack of first class FP, beyond the type checking stuff, may actually at root be part of the problem: if Python had somehow become the FP rich language it said "nope, different model" -then parallelism and GIL would be a totally different argument.
Maybe I was mis-informed. FP interests me but I am not rich in experience. Maybe its an oversold idea?