Write Pythonic Code in Python

Writing Pythonic code means writing Python the way experienced Python developers write it. It is not about following every rule in a style guide. It is about using the language's built-in features as they were designed to be used, so your code reads naturally to anyone who knows Python well.

A programmer coming from Java might write a loop with an index variable and manual list access. A Pythonic programmer writes a list comprehension or uses enumerate. Both produce the same result, but the Pythonic version is shorter, clearer, and often faster because it uses C-level optimizations inside the interpreter.

Learning to write Pythonic code is the difference between writing Python that merely works and writing Python that other developers enjoy reading. If you have followed the earlier sections on Python collections and Python functions, you already have the foundation. This article connects those skills into an idiomatic style.

The second version below reads like English: "for each index and name in the enumerated list, print both." The first version forces the reader to mentally parse range(len(...)) before understanding the intent.

python

# Not Pythonic: index-based loop
names = ["Ada", "Grace", "Alan"]
for i in range(len(names)):
    print(f"{i}: {names[i]}")
 
# Pythonic: use enumerate
for i, name in enumerate(names):
    print(f"{i}: {name}")

List comprehensions over manual loops

A list comprehension builds a new list by applying an expression to each item in an iterable, optionally filtering with an if clause. The syntax reads left to right in a way that mirrors the result you want. It replaces the pattern where you create an empty list, loop over something, and append.

python

# Not Pythonic: manual loop with append
squares = []
for n in range(10):
    if n % 2 == 0:
        squares.append(n ** 2)

The comprehension version says it directly: squares is n squared for each n in 0 through 9, when n is even. No setup lines, no append calls.

python

# Pythonic: list comprehension
squares = [n ** 2 for n in range(10) if n % 2 == 0]

Comprehensions also work for dictionaries and sets. A dict comprehension builds a mapping from an iterable, and a set comprehension collects unique values:

python

word = "mississippi"
letter_counts = {ch: word.count(ch) for ch in set(word)}
# Result: {'p': 2, 's': 4, 'i': 4, 'm': 1}
 
unique_lengths = {len(name) for name in ["Ada", "Grace", "Alan"]}
# Result: {3, 4, 5}

Do not force a comprehension when the logic is complex. If the expression or condition spans multiple lines, use a regular loop. A comprehension should be readable at a glance.

Tuple unpacking instead of index access

When a function returns a tuple, or when you iterate over pairs, unpack the values directly into named variables. Index access is noisy and forces the reader to remember what lives at position 0, 1, and 2.

python

# Not Pythonic: index-based access
point = (3, 7)
x = point[0]
y = point[1]
 
for pair in [("Ada", 28), ("Grace", 32)]:
    print(f"{pair[0]} is {pair[1]} years old")

The unpacking version names each part, so the reader sees x and y instead of point[0] and point[1]. The loop body reads like a plain sentence.

python

# Pythonic: tuple unpacking
x, y = (3, 7)
 
for name, age in [("Ada", 28), ("Grace", 32)]:
    print(f"{name} is {age} years old")

Unpacking also handles swapping without a temporary variable. In many languages, swapping two values requires three lines. In Python, it is one:

python

a, b = b, a

The right side evaluates first, creating a temporary tuple (b, a), which is then unpacked into a and b. This is both Pythonic and safe.

Use enumerate instead of range(len(...))

The pattern range(len(some_list)) is a habit carried over from languages that do not have a built-in way to get both the index and the value during iteration. Python has enumerate for exactly this purpose.

python

# Not Pythonic: manual index tracking
colors = ["red", "green", "blue"]
for i in range(len(colors)):
    print(f"{i + 1}. {colors[i]}")

Enumerate gives you the index and the value together, and the optional start argument lets you begin counting from 1 instead of 0 for user-facing output.

python

# Pythonic: use enumerate with start
for i, color in enumerate(colors, start=1):
    print(f"{i}. {color}")

Use zip to iterate over multiple sequences together

When you need to walk through two or more lists in lockstep, zip pairs them up cleanly. Index-based parallel iteration is a common non-Pythonic pattern that forces the reader to track multiple index lookups.

python

names = ["Ada", "Grace", "Alan"]
scores = [92, 88, 95]
 
# Not Pythonic: parallel index iteration
for i in range(len(names)):
    print(f"{names[i]} scored {scores[i]}")

Zip pairs elements position by position and stops at the shortest input. For strict pairing that raises an error on mismatched lengths, use zip with strict=True from Python 3.10 onward.

python

# Pythonic: zip pairs elements together
for name, score in zip(names, scores):
    print(f"{name} scored {score}")

Context managers for resource handling

Files, network connections, and locks need to be closed or released, even when an error occurs. The non-Pythonic approach uses try and finally manually. The Pythonic approach uses the with statement.

python

# Not Pythonic: manual try/finally
file = open("data.txt", "r")
try:
    content = file.read()
finally:
    file.close()

The with statement guarantees the file is closed when the block exits, whether by reaching the end, returning early, or raising an exception. No manual cleanup code needed.

python

# Pythonic: with statement handles cleanup
with open("data.txt", "r") as file:
    content = file.read()

This pattern is covered in depth in the section on Python context managers.

Truthiness checks instead of explicit comparisons

Python objects have a truth value. Empty collections, zero numbers, and None are falsy. Non-empty collections, non-zero numbers, and most objects are truthy. Use this directly instead of comparing to True, False, or None.

python

# Not Pythonic: explicit comparisons
if len(items) > 0:
    process(items)
 
if value is True:
    activate()

The Pythonic version relies on Python's truthiness rules. An empty list is falsy, a non-empty list is truthy. The condition reads like natural language.

python

# Pythonic: truthiness checks
if items:
    process(items)
 
if value:
    activate()

Note the one exception: comparing to None should use is and is not, not == and !=. None is a singleton, and is checks identity rather than equality.

Join strings instead of concatenating in a loop

Building a string by repeatedly adding with + in a loop creates a new string object each time. Python strings are immutable, so each + allocates and copies. Use str.join or collect parts in a list and join once.

python

words = ["Python", "is", "readable"]
 
# Not Pythonic: repeated concatenation
sentence = ""
for word in words:
    sentence += word + " "
sentence = sentence.strip()

Join takes an iterable of strings and combines them with the separator. It is a single call instead of a loop, and it is implemented in C for speed.

python

# Pythonic: use str.join
sentence = " ".join(words)

If you are building a string from pieces that are not already in a list, collect them first and join at the end:

python

parts = []
for i in range(1, 6):
    parts.append(f"step {i}")
result = " -> ".join(parts)
# Result: 'step 1 -> step 2 -> step 3 -> step 4 -> step 5'

Pythonic ways to check for membership

Use the in operator to check whether a value exists in a collection. It reads like natural language and works on lists, tuples, sets, dictionaries, and strings. A set is the right choice for membership tests because lookups are O(1). On a list, in performs a linear scan.

python

vowels = {"a", "e", "i", "o", "u"}
 
# Not Pythonic: chained equality checks
def is_vowel(ch):
    return ch == "a" or ch == "e" or ch == "i" or ch == "o" or ch == "u"
 
# Pythonic: membership test with a set
def is_vowel(ch):
    return ch in vowels

Choosing the right collection type for the job, such as a set instead of a list for membership tests, is part of the same Pythonic mindset.

Slicing instead of manual sublist extraction

Python's slice syntax reads cleanly and handles edge cases that manual loops would need extra code for. Even if a slice index is out of bounds, Python handles it gracefully by returning what is available.

python

items = ["a", "b", "c", "d", "e"]
 
first_three = items[:3]       # ['a', 'b', 'c']
last_two = items[-2:]          # ['d', 'e']
middle = items[1:4]            # ['b', 'c', 'd']
reversed_items = items[::-1]   # ['e', 'd', 'c', 'b', 'a']

Default dictionaries over manual key checking

When you need to group values by a key or count occurrences, collections.defaultdict removes the boilerplate of checking whether a key exists before using it. The manual approach requires an if-check before every first access.

python

from collections import defaultdict
 
# Not Pythonic: manual key existence check
counts = {}
for word in ["a", "b", "a", "c", "b", "a"]:
    if word not in counts:
        counts[word] = 0
    counts[word] += 1

defaultdict(int) creates new entries with a default value of 0 when a key is accessed for the first time. The counting logic becomes a single line.

python

# Pythonic: defaultdict handles missing keys
counts = defaultdict(int)
for word in ["a", "b", "a", "c", "b", "a"]:
    counts[word] += 1

The Pythonic mindset

Writing Pythonic code is a habit, not a checklist. When you catch yourself writing a loop that creates an empty list and fills it with append, pause and ask whether a comprehension would be clearer. When you write range(len(...)), ask whether enumerate fits better. When you manually open and close a resource, ask whether with would be safer.

These patterns are about communicating intent. A list comprehension says "I am building a new list from this iterable." A with statement says "I am managing a resource that must be released." Tuple unpacking says "I am working with a fixed sequence of values." Each construct tells the reader what is happening without requiring them to parse the mechanics.

The next step is to apply these patterns when you write new code. Do not rewrite old working code just to make it more Pythonic. But when you write something new, reach for the idiomatic tool first.