Learn Why You Should Care About PEPs: Absolute Beginners Tutorial

You will encounter the term PEP within your first week of learning Python. Most tutorials tell you it stands for Python Enhancement Proposal and then move on. This tutorial does not do that. Here you will learn exactly what PEPs are, why they were created, and — more importantly — why two specific PEPs will change how you write Python code starting today.

Python is a language used by millions of developers worldwide. For that ecosystem to function, everyone writing Python needs to work from a shared understanding of what good Python looks like. That shared understanding comes from PEPs — numbered design documents that govern how the language evolves and how code in it should be written. Some PEPs add features to the language. Others define how you format a variable name. Once you understand the system, a lot of Python behavior that previously seemed arbitrary will start to make sense.

What Is a PEP and Why Does It Exist?

A Python Enhancement Proposal is a formal design document used to communicate ideas to the Python community. PEP 1, which describes the purpose and guidelines for writing PEPs, defines them as the primary mechanism for proposing major new features, collecting community input on issues, and documenting design decisions. That is a lot to take in, so here is a more grounded way to think about it.

Imagine you are working on a large open-source project with thousands of contributors. Someone wants to add a new feature. How does that idea get submitted, debated, and approved without chaos? PEPs are that process. They give every proposal a number, a structure, a status, and a paper trail. Because PEPs are stored as text files in a public version control repository, the full history of every proposal — including rejected ones — is permanently available at peps.python.org.

PEPs are not just for core developers. Informational PEPs — including the ones you will use the most as a beginner — are written for the entire Python community. They define how Python developers are expected to think, write, and structure code. Learning to recognize PEP references in documentation, linter output, and code reviews is a practical skill that pays off immediately.

The Three Types of PEPs

Not all PEPs propose new language features. There are three distinct categories, and understanding the difference tells you exactly what kind of information you are reading when you open one.

PEP 8: The Style Guide That Shapes Your Code

PEP 8 is the document that will affect your daily work the most. It defines the official coding style for Python — covering indentation, spacing, naming, line length, comments, and more. It was adapted from Guido van Rossum's original Python Style Guide essay and has been updated over time as the language evolved.

When you read Python documentation, open-source code, or Stack Overflow answers from experienced developers, you are looking at code shaped by PEP 8. When a linter like flake8 or an IDE like VS Code underlines part of your code, it is often enforcing a PEP 8 rule. Understanding the rules directly — rather than just relying on automated tools — makes you a more intentional programmer.

"Code is read much more often than it is written." — PEP 8 (Guido van Rossum)

Naming Conventions

PEP 8 is specific about how things should be named. Variables and functions use snake_case. Class names use PascalCase. Constants use ALL_CAPS. These are not personal preferences — they are the agreed standard that makes it possible for any Python developer to read your code and immediately understand what each identifier represents.

# PEP 8 naming conventions

# Variables and functions — snake_case
user_name = "ada"
page_count = 42

def calculate_total(price, quantity):
    return price * quantity

# Classes — PascalCase
class ShoppingCart:
    pass

# Constants — ALL_CAPS
MAX_RETRY_LIMIT = 3
DEFAULT_TIMEOUT = 30

Indentation and Line Length

Python requires indentation to define code blocks, but PEP 8 specifies exactly how to do it: 4 spaces per level, never tabs. The maximum recommended line length for code is 79 characters. If a line of code is longer, you break it with parentheses or a backslash. These rules exist because different editors, terminals, and code review tools handle whitespace differently — a consistent approach avoids subtle bugs and visual inconsistencies.

# Good: 4-space indentation, line break with parentheses
def send_notification(user_id, message, priority,
                      retry_on_failure=True):
    if priority == "high":
        dispatch_immediately(user_id, message)
    else:
        queue_message(user_id, message)

# Bad: tabs mixed with spaces — causes IndentationError in Python 3
def bad_example():
	x = 1  # tab used here — do not do this

PEP 20: The Zen of Python

PEP 20 is an informational PEP that contains 19 aphorisms describing the guiding philosophy behind Python. You can read it any time by running import this in a Python interpreter. The principles are short — each is a single sentence — but they encode a philosophy that distinguishes Python from other languages. Ideas like "Readability counts," "Explicit is better than implicit," and "Simple is better than complex" are not decorative sayings. They explain why Python looks the way it does and why the community rejects code that is clever at the expense of clarity.

# Run this in any Python interpreter to see PEP 20
import this

"Readability counts." — PEP 20, The Zen of Python

Python Learning Summary Points

1. A PEP is a numbered design document that serves as the formal mechanism for proposing features, collecting community input, and documenting Python design decisions. All PEPs — accepted, rejected, and superseded — are permanently available at peps.python.org.
2. There are three categories of PEPs: Standards Track (propose language or library changes), Informational (document guidelines and philosophy without mandating change), and Process (govern workflows and community decision-making). As a beginner, the Informational PEPs — especially PEP 8 and PEP 20 — will shape your code the most immediately.
3. PEP 8 defines the official Python style guide: 4-space indentation, snake_case for variables and functions, PascalCase for classes, ALL_CAPS for constants, and a maximum line length of 79 characters. These rules exist to make code consistent and readable across the entire ecosystem, not just within a single project.
4. PEP 20, the Zen of Python, encodes the philosophy behind Python's design in 19 aphorisms. Running import this in any Python interpreter displays them. The principles explain why Python looks and behaves the way it does — and why the community values clarity over cleverness.

PEPs are the governance layer beneath everything Python. You do not need to read every PEP to write good Python code. You do need to understand that the conventions you will encounter — in linters, in open-source projects, in code reviews — trace back to decisions documented in these proposals. The two PEPs covered here, PEP 8 and PEP 20, are a practical starting point. Once they become second nature, the rest of the system will make more sense.