When we use Python for functional programming, we embark down a path that will involve a hybrid that's not strictly functional. Python is not Haskell, OCaml, or Erlang. For that matter, our underlying processor hardware is not functional; it's not even strictly object-oriented, CPUs are generally procedural.
It's turtles all the way down.
There's no practical end to the layers of abstractions.
More importantly, the presence of abstractions and virtual machines doesn't materially change our approach to designing software to exploit the functional programming features of Python.
Even within the functional programming community, there are both purer and less pure functional programming languages. Some languages make extensive use of monads to handle stateful things such as file system input and output. Other languages rely on a hybridized environment that's similar to the way we use Python. In Python, software can be generally functional, with carefully chosen procedural exceptions.
Our functional Python programs will rely on the following three stacks of abstractions:
- Our applications will be functions—all the way down—until we hit the objects
- The underlying Python runtime environment that supports our functional programming is objects—all the way down—until we hit the libraries
- The libraries that support Python are a turtle on which Python stands
The operating system and hardware form their own stack of turtles. These details aren't relevant to the problems we're going to solve.