Blog Post #108: lambda vs. def: When to Use Which

by

In Post #106 and Post #107, we explored lambda functions—Python’s tool for creating small, anonymous one-liners. We saw that they are particularly useful as arguments for higher-order functions like sorted(), map(), and filter().

This naturally leads to a question of style and best practice: when should you use a concise lambda, and when should you stick with a standard def function? In this post, we’ll provide clear guidelines to help you choose the right tool for the job.

A Quick Recap: The Core Differences

Let’s first summarize the fundamental differences between the two.

def statements:

  • Create a named function.
  • Can contain any number of statements in their body (multiple lines, if statements, loops, etc.).
  • Can have a formal docstring.
  • Are designed for reusability, complexity, and clarity.

lambda expressions:

  • Create an anonymous (unnamed) function.
  • Are restricted to a single expression. The result of this expression is implicitly returned.
  • Cannot have a docstring.
  • Are designed for short, single-use, “throwaway” functions.

The Case for lambda

The primary and best use case for a lambda is for short, simple functions that you pass as an argument to a higher-order function.

When the logic is simple enough to be clear and obvious in one line, a lambda is wonderfully concise. It keeps the logic right where it’s being used, rather than forcing you to look elsewhere in the code for a def statement.

names = ["Christopher", "Ana", "David", "Jennifer"]

# GOOD: The lambda is short, simple, and its purpose is immediately clear.
# It provides a key to sort the names by their length.
sorted_by_length = sorted(names, key=lambda name: len(name))

print(sorted_by_length)

Output: ['Ana', 'Bob', 'David', 'Alice']

The Case for def

For nearly every other situation, a def statement is the better choice. The guiding principle for this decision is always readability.

1. For Complex Logic

This is a hard rule. If your logic requires multiple lines, if statements, loops, or creating temporary variables, you have no choice—you must use def. A lambda can only contain a single expression.

2. For Reusability

If you plan to use a function more than once, give it a name with def. This follows the DRY (Don’t Repeat Yourself) principle we learned in Post #83. While you can assign a lambda to a variable, the official Python style guide (PEP 8) advises against it.

  • Bad Practice: add = lambda x, y: x + y
  • Good Practice:Pythondef add(x, y): return x + y

If a piece of logic is important enough to have a name, use def to give it a proper one.

3. For Readability (The Most Important Reason)

If your lambda expression becomes long or complicated, it stops being a “simple” function and becomes hard to read. In these cases, a named def function is much clearer because the function’s name can describe its purpose.

  • Hard to Read:Python# This lambda is too complex and hard to parse at a glance data = sorted(my_list_of_dicts, key=lambda item: (item['priority'], -item['score']))
  • Much Clearer:Pythondef get_sort_key(item): """Returns a tuple for sorting: priority ascending, score descending.""" return (item['priority'], -item['score']) # The sorted() call is now much more readable data = sorted(my_list_of_dicts, key=get_sort_key)

What’s Next?

The choice between lambda and def comes down to a simple trade-off between conciseness and readability. Use lambda for trivial, single-use functions passed as arguments. For everything else—reusable logic, multi-step operations, or complex expressions—prefer the clarity and power of a named def function.

We’ve now spent a lot of time learning how to write and organize code within a single file using functions. But as our projects grow, putting everything in one giant file becomes unmanageable. The next step in our journey is to learn how to split our code across multiple files. In Post #109, we will learn how to create and use our very first module.

Author

Debjeet Bhowmik

Experienced Cloud & DevOps Engineer with hands-on experience in AWS, GCP, Terraform, Ansible, ELK, Docker, Git, GitLab, Python, PowerShell, Shell, and theoretical knowledge on Azure, Kubernetes & Jenkins. In my free time, I write blogs on ckdbtech.com

Leave a Comment