Guido van Rossum Style Guide⁠‍⁠​‌​‌​​‌‌‍​‌​​‌​‌‌‍​​‌‌​​​‌‍​‌​​‌‌​​‍​​​​​​​‌‍‌​​‌‌​‌​‍‌​​​​​​​‍‌‌​​‌‌‌‌‍‌‌​​​‌​​‍‌‌‌‌‌‌​‌‍‌‌​‌​​​​‍​‌​‌‌‌‌‌‍​‌​​‌​‌‌‍​‌‌​‌​​‌‍‌​‌​‌‌‌​‍​​‌​‌​​​‍‌‌‌​‌​‌‌‍‌‌​​​‌‌‌‍‌​​‌​​​‌‍​‌​‌​‌​‌‍​​​‌‌‌‌​‍​​​​‌​‌​‍​​‌‌​‌​‌⁠‍⁠

Overview

Guido van Rossum created Python in 1989 and served as its "Benevolent Dictator For Life" (BDFL) until 2018. His design philosophy—that code is read far more than it's written—shapes every aspect of Python and defines what "Pythonic" means.

Core Philosophy

"Readability counts."

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

"Simple is better than complex. Complex is better than complicated."

Van Rossum believes programming languages should be tools for humans first, not just instructions for machines. Python's design prioritizes clarity over cleverness.

Design Principles

Readability is Paramount: Code should read like well-written prose. If you need comments to explain what code does, the code should be clearer.

Explicit over Implicit: Don't hide behavior. Make operations visible and obvious.

One Obvious Way: Resist adding features that provide multiple ways to do the same thing.

Practicality over Purity: Don't sacrifice usability for theoretical elegance.

When Writing Code

Always

• Use meaningful, descriptive names (user_count not uc )

• Follow PEP 8 style guidelines

• Use Python's built-in data structures (lists, dicts, sets)

• Leverage the standard library before reaching for third-party packages

• Write docstrings for public functions and classes

• Use context managers (with ) for resource management

• Prefer exceptions over error codes

Never

• Write clever one-liners that sacrifice readability

• Use single-letter variable names (except i , j for indices, x , y for coordinates)

• Ignore PEP 8 without good reason

• Use from module import * in production code

• Catch bare except: without re-raising

• Use mutable default arguments

Prefer

• List comprehensions over map /filter when readable

• enumerate() over manual index tracking

• zip() over parallel index iteration

• f-strings over .format() or % formatting

• pathlib.Path over os.path operations

• collections types when they fit (Counter, defaultdict, namedtuple)

Code Patterns

Pythonic Iteration

BAD: C-style iteration

for i in range(len(items)): print(items[i])

GOOD: Direct iteration

for item in items: print(item)

BAD: Manual index tracking

i = 0 for item in items: print(i, item) i += 1

GOOD: enumerate

for i, item in enumerate(items): print(i, item)

BAD: Parallel lists with indices

for i in range(len(names)): print(names[i], ages[i])

GOOD: zip

for name, age in zip(names, ages): print(name, age)

Pythonic Conditionals

BAD: Verbose boolean checks

if len(items) > 0: process(items)

if value == True: do_something()

if value == None: handle_none()

GOOD: Truthy/falsy checks

if items: process(items)

if value: do_something()

if value is None: handle_none()

Pythonic String Building

BAD: String concatenation in loop

result = "" for item in items: result += str(item) + ", "

GOOD: join

result = ", ".join(str(item) for item in items)

BAD: Old-style formatting

message = "Hello, %s! You have %d messages." % (name, count)

GOOD: f-strings (Python 3.6+)

message = f"Hello, {name}! You have {count} messages."

Pythonic Resource Management

BAD: Manual resource management

f = open('file.txt') try: data = f.read() finally: f.close()

GOOD: Context manager

with open('file.txt') as f: data = f.read()

Works for any resource: files, locks, connections, etc.

with database.connection() as conn: with conn.cursor() as cursor: cursor.execute(query)

Pythonic Dictionary Operations

BAD: Verbose key checking

if key in d: value = d[key] else: value = default

GOOD: get with default

value = d.get(key, default)

BAD: Check before insert

if key not in d: d[key] = [] d[key].append(item)

GOOD: setdefault or defaultdict

d.setdefault(key, []).append(item)

Or better:

from collections import defaultdict d = defaultdict(list) d[key].append(item)

Mental Model

Van Rossum thinks of code as communication with future readers (including yourself). When writing:

• Write for the reader: Would someone unfamiliar with this code understand it?

• Use the right abstraction level: Not too low (manual), not too high (magical)

• Follow conventions: Consistency reduces cognitive load

• Leverage the language: Use Python's features, don't fight them

BDFL Decisions

Key design decisions that define Python:

• Significant whitespace: Forces readable structure

• No braces: Reduces visual clutter

• Duck typing: "If it walks like a duck..."

• Batteries included: Rich standard library

• Explicit self: Methods clearly show instance access