Written for people first: readability, indentation and great Python code
October 21, 2026 · 19 min read
Guido van Rossum describes programs as recipes written for two audiences and explains why readability matters, Chris Lattner weighs Python's strengths and the indentation debate while building Mojo on top of it, and The Hitchhiker's Guide to Python gives whole sections to writing and reading great code. Together they show why the people who build and teach Python treat code as something humans must read, not only something a machine must run.
The rules, numbers and steps worth keeping in front of you.
- Van Rossum: a program has two audiences, the computer and the programmers who read, debug and improve it.
- Software is never right the first time; it is debugged and improved continually by teams or its author.
- Van Rossum: even a lone programmer should adopt formatting conventions.
- In Python, indentation is part of the language: everything in a block must be indented the same way.
- Four spaces is a convention shaped by history and screen widths; two, six or twelve also work.
- Lattner's case for indentation: formatters already enforce it, misleading indentation causes bugs, one grouping rule removes clutter.
- Mojo keeps indentation and says no to braces.
- Name variables and functions for the reader; reading code takes your whole brain (van Rossum).
- Python's type hints are checked by a separate static checker, not at runtime; Mojo enforces declared types.
- Use types on large or shared codebases; leave prototypes free (van Rossum, Lattner).
- Hitchhiker's Guide: follow PEP 8 and the Zen of Python, including "readability counts."
- Watch for mutable default arguments and late-binding closures.
- Ship tests, documentation, logging and a license as if others will use your code.
- Read respected projects such as Requests and Flask to learn their patterns.
This is the short form. The full insight has every expert's reasoning, their own words and the sources.