In this article, you’ll learn what the functional paradigm is as well as how to use functional programming in Python. You’ll also learn about list comprehensions and other forms of comprehensions.

No time to read this?

Sign up and you'll get this blog post in PDF. You'll also get some extra content that isn't in this blogpost ✨

    We won't send you spam. Unsubscribe at any time.

    Powered By ConvertKit

    Functional paradigm

    In an imperative paradigm, you get things done by giving the computer a sequence of tasks and then it executes them. While executing them, it can change states. For example, let’s say you originally set A to 5, then later on you change the value of A. You have variables in the sense that the value inside the variable varies.

    In a functional paradigm, you don’t tell the computer what to do but rather you tell it what stuff is. What the greatest common divisor of a number is, what the product from 1 to n is and so on.

    Because of this, variables cannot vary. Once you set a variable, it stays that way forever (note, in purely functional languages they are not called variables). Because of this, functions have no side effects in the functional paradigm. A side effect is where the function changes something outside of it. Let’s look at an example of some typical Python code:

    The output for this code is 5. In the functional paradigm, changing variables is a big no-no and having functions affect things outside of their scope is also a big no-no. The only thing a function can do is calculate something and return it as a result.

    Now you might be thinking: “no variables, no side effects? Why is this good?”. Good question, gnarly stranger reading this.

    If a function is called twice with the same parameters, it’s guaranteed to return the same result. If you’ve learnt about mathematical functions, you’ll know to appreciate this benefit. This is called referential transparency. Because functions have no side effects, if you are building a program which computes things, you can speed up the program. If the program knows that func(2) equates to 3, we can store this in a table. This prevents the program from repeatedly running the same function when we already know the answer.

    Typically, in functional programming, we do not use loops. We use recursion. Recursion is a mathematical concept, usually, it means “feeding into itself”. With a recursive function, the function repeatedly calls itself as a sub-function. Here’s a nice example of a recursive function in Python:

    Some programming languages are also lazy. This means that they don’t compute or do anything until the very last second. If you write some code to perform 2 + 2, a functional program will only calculate that when you actually need to use the resultant. We’ll explore laziness in Python soon.


    Map

    To understand map, let’s first look at what iterables are. An iterable is anything you can iterate over. Typically these are lists or arrays, but Python has many different types of iterables. You can even create your own objects which are iterable by implementing magic methods. A magic method is like an API that helps your objects become more Pythonic. You need to implement 2 magic methods to make an object an iterable:

    The first magic method, “__iter__” or dunder iter (double underscore iter) returns the iterative object, this is often used at the start of a loop. Dunder next returns what the next object is.

    Let’s go into a quick terminal session and check this out:

    This will print

    3
    4
    5
    6
    7
    8

    In Python, an iterator is an object which only has an __iter__ magic method. This means that you can access positions in the object, but cannot iterate through the object. Some objects will have the magic method __next__ and not the __iter__ magic method, such as sets (talked about later in this article). For this article, we’ll assume everything we touch is an iterable object.

    So now we know what an iterable object is, let’s go back to the map function. The map function lets us apply a function to every item in an iterable. Typically we want to apply a function to every item in a list, but know that it’s possible for most iterables. Map takes 2 inputs, the function to apply and the iterable object.

    Let’s say we have a list of numbers like so:

    [1, 2, 3, 4, 5]

    And we want to square every number, we can write code like this:

    Functional functions in Python are lazy. If we didn’t include the “list()” the function would store the definition of the iterable, not the list itself. We need to explicitly tell Python “turn this into a list” for us to use this.

    It’s a bit weird to go from non-lazy evaluation to lazy evaluation all of a sudden in Python. You’ll eventually get used to it if you think more in the functional mindset than an imperative mindset.

    Now it’s nice to write a normal function like “square(num)” but it doesn’t look right. We have to define a whole function just to use it once in a map? Well, we can define a function in map using a lambda (anonymous) function.


    Lambda expressions

    A lambda expression is a one line function. Take, for instance, this lambda expression which squares a number given to it:

    Now let’s run this:

    >>> square(3)
    9

    I hear you. “Brandon, where are the arguments? what the heck is this? that doesn’t look anything like a function?”

    Well, it’s kind of confusing but can be explained. So we’re assigning something to the variable “square”. this part:

    Tells Python that this is a lambda function, and the input is called x. Anything after the colon is what you do with the input, and it automatically returns whatever the resultant of that is.

    To simplfy our square program into one line we can do:

    So in a lambda expression, all the arguments go on the left and the stuff you want to do with them go on the right. It gets a little messy, no one can deny that. The truth is that there’s a certain pleasure in writing code that only other functional programmers can read. Also, it’s super cool to take a function and turn it into a one-liner.


    Reduce

    Reduce is a function that turns an iterable into one thing. Typically you perform a computation on a list to reduce it down to one number. Reduce looks like this:

    We can (and often will) use lambda expressions as the function.

    The product of a list is every single number multiplied together. To do this you would program:

    But with reduce you can just write:

    To get the same product. The code is shorter, and with knowledge of functional programming it is neater.


    Filter

    The filter function takes an iterable and filters out all the things you don’t want in that iterable.

    Normally filter takes a function and a list. It applies the function to each item in the list and if that function returns True, it does nothing. If it returns False, it removes that item from the list.

    The syntax looks like:

    Let’s see a small example, without filter we’ll write:

    With filter, this becomes:


    Higher order functions

    Higher order functions can take functions as parameters and return functions. A very simple example would look like:

    Or an even simpler example of the second definition, “return functions”, is:

    You know earlier how I said that pure functional programming languages didn’t have variables? Well, higher order functions are what makes this easier. You don’t need to store a variable anywhere if all you’re doing is passing data through a long tunnel of functions.

    All functions in Python are first class objects. A first class object is defined as having one or more of these features:

    • Created at runtime
    • Assigned to a variable or element in a data structure
    • Passed as an argument to a function
    • Returned as the result of a function

    So all functions in Python are first class and can be used as a higher order function.


    Partial application

    Partial application (also called closures) is a bit weird, but are super cool. You can call a function without supplying all the arguments it requires. Let’s see this in an example. We want to create a function which takes 2 arguments, a base and an exponent, and returns base to the power of the exponent, like so:

    Now we want to have a dedicated square function, to work out the square of a number using the power function:

    This works, but what if we want a cube function? or a function to the power of 4? Can we keep on writing them forever? Well, you could. But programmers are lazy. If you repeat the same thing over and over again, it’s a sign that there is a much quicker way to speed things up and that will allow you to not repeat things. We can use partial applications here. Let’s see an example of the square function using a partial application:

    Isn’t that cool! We can call functions which require 2 arguments, using only 1 argument by telling Python what the second argument is.

    We can also use a loop, to generate a power function that works from cubed all the way up to powers of 1000.


    Functional programming isn’t Pythonic

    You might have noticed, but a lot of the things we want to do in functional programming revolve around lists. Other than the reduce function & partial application, all the functions you have seen generate lists. Guido (the inventor of Python) dislikes functional stuff in Python because Python already has its own way to generate lists.

    If you write “import this” into a Python IDLE session, you’ll get:

    >>> import this
    The Zen of Python, by Tim Peters
    
    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

    This is the Zen of Python. It’s a poem about what something being Pythonic means. The part we want to relate to here is:

    There should be one — and preferably only one — obvious way to do it.

    In Python, map & filter can do the same things as a list comprehension (discussed next) can do. This breaks one of the rules of the Zen of Python, so these parts of functional programming aren’t seen as ‘pythonic’.

    Another talking point is Lambda. In Python, a lambda function is a normal function. Lambda is syntactic sugar. Both of these are equivalent:

    A regular function can do everything a lambda function can, but it doesn’t work the other way around. A lambda function cannot do everything that a regular function can do.

    This was a short argument about why functional programming doesn’t fit into the whole Python ecosystem very well. You may have noticed I mentioned list comprehensions earlier, we’ll discuss them now.


    List comprehensions

    Earlier, I mentioned that anything you could do with map or filter, you could do with a list comprehension. This is the part where we’ll learn about them.

    A list comprehension is a way to generate lists in Python. The syntax is:

    So let’s square every number in a list, as an example:

    Okay, so we can see how we can apply a function to every item in a list. How do we go around applying a filter? Well, look at this code from earlier:

    We can convert this into a list comprehension like so:

    List comprehensions support if statements like this. You no longer need to apply a million functions to something to get what you want. In fact, if you’re trying to make some kind of list chances are that it’ll look cleaner and easier using a list comprehension.

    What if we want to square every number below 0 in a list? Well, with lambda, map and filter you’ll write:

    So that’s seems really long and slightly complicated. With a list comprehension it’s just:

    A list comprehension is only good for, well, lists. Map and filter work on any iterable, so what’s up with that? Well, you can use any comprehension for any iterable object you encounter.


    Other comprehensions

    You can create a comprehension of any iterable

    Any iterable can be generated using a comprehension. Since Python 2.7, you can even generate a dictionary (hashmap).

    If it’s an iterable, it can be generated. Let’s look at one last example of sets. If you don’t know what a set is, check out this other article I wrote. The TLDR is:

    • Sets are lists of elements, no element is repeated twice in that list
    • The order in sets do not matter.

    You may notice that sets have the same curly braces as dictionaries.  Python is really smart. It’ll know whether you’re writing a dictionary  comprehension or a set comprehension based on whether you provide the  extra value for the dictionary or not. If you want to learn more about  comprehensions, check out this visual guide. If you want to learn more about comprehensions & generators, check out this article.


    Conclusion

    Functional programming is beautiful and pure. Functional code can be clean, but it can also be messy. Some hardcore Python programmers dislike the functional paradigm in Python. You should use what you want to use, use the best tool for the job.


    Hey 👋 Want to subscribe to my blog and stay up to date with posts similar to this one? Subscribe to my email list below. I won't spam you. I will only send you posts similar to this one 😊✨

    No time to read this?

    Sign up and you'll get this blog post in PDF. You'll also get some extra content that isn't in this blogpost ✨

      We won't send you spam. Unsubscribe at any time.

      Powered By ConvertKit

      If you're feeling extra generous, I have a PayPal and even a Patreon. I'm  a university student who writes these blogs in their spare time. This blog is my full time job, so any and all donations are appreciated! 😁