Summary: The Hitchhiker's Guide to Python

The GIST

The Hitchhiker's Guide to Python by Kenneth Reitz and Tanya Schlusser is a field guide to working the way experienced Python developers work. Published by O'Reilly in 2016 with the subtitle Best Practices for Development, it is not a tutorial and will not teach you the language. In the words of its Preface, it "is not intended to teach you the Python language" but is "an (opinionated) insider's guide to our community's favorite tools and best practices." Think of it as the conversation you would have with a seasoned colleague on your first week at a Python shop: which version to install, how to lay out a project, what good code looks like, which libraries people actually trust.

Its origins are what make it unusual. The book is the print edition of a free, open-source website, a "living, breathing guide" that the Python community writes together, and the publisher credits over a hundred members of that community as contributors. Reitz, best known as the creator of the hugely popular Requests library, started the online guide; Schlusser, a consultant with more than two decades of experience across half a dozen languages, helped shape it into a book. The worry behind it is simple. Python was built on a philosophy of simplicity, but success brings sprawl, and a language used by so many people for so many things risks losing the shared habits that made it pleasant. This book tries to write those habits down.

The Big Ideas

Python is big, so you need an opinionated map

The title tips its hat to Douglas Adams, and the Preface opens with a parody of his famous line about space: "Python is big. Really big. You just won't believe how vastly hugely mind-bogglingly big it is." That is the problem the book sets out to solve. The language itself is small and friendly. The world around it, with its interpreters, installers, editors, frameworks and thousands of libraries, is enormous, and a newcomer can waste months choosing among them.

The authors' answer is to have opinions. Where most references list every option evenly, this one recommends. The publisher describes it as light on reusable code and heavy on design philosophy, and it constantly points the reader to excellent sources that already exist rather than repeating them. The tone is friendly and a little playful throughout. The promise is that a "journeyman Pythonista" can be taken toward real expertise by absorbing what the community already agrees on.

Set up your workshop properly

Part I, Getting Started, covers the unglamorous foundation in three chapters: picking an interpreter, properly installing Python, and choosing a development environment.

The first chapter confronts the question that dominated Python in 2016, the long migration from Python 2 to Python 3, under the cheerful heading "So…3?" The book's general recommendation is Python 3 for new projects, with 2.7 tolerated only where an essential library demanded it. It then tours the family of Python implementations beyond the standard CPython: PyPy for speed, Jython for the Java world, IronPython and PythonNet for .NET, Skulpt for the browser and MicroPython for microcontrollers. This is the most dated part of the book, since Python 2 reached the end of its life in 2020 and the question has answered itself.

The installation chapter walks through setup on macOS, Linux and Windows and introduces the habit the authors most want you to form: giving each project its own virtual environment, so that one project's dependencies never trample another's. The third chapter surveys text editors and full development environments, enhanced interactive shells and isolation tools. Its advice is practical rather than doctrinaire: use what works for you, but know what is out there.

Writing great code

Part II, Getting Down to Business, is the heart of the book, and it begins with the chapter most readers come for. Its starting point is style. PEP 8 is the community's style guide, the shared set of conventions that makes one person's Python look like another's. PEP 20, better known as the Zen of Python, sets out the values underneath, in aphorisms by Tim Peters such as "explicit is better than implicit" and "readability counts." The authors treat these not as decoration but as the test of whether code is Pythonic: clear, direct and written to be read by humans.

From there the chapter gets concrete. It covers the idioms experienced developers reach for and the classic traps that catch everyone once, such as mutable default arguments and late-binding closures. It explains how to structure a project, from the layout of the repository to the use of modules and packages, on the principle that structure is the key to code people can navigate. It discusses object-oriented programming, decorators, context managers, dynamic typing and the difference between mutable and immutable types.

And it insists that code is not finished when it runs. A project needs tests, documentation, sensible logging, which libraries and applications need in different ways, and a deliberate choice of open-source license. The underlying attitude is that you should build everything as if other people will use it, because sooner or later they will.

Reading great code

The fifth chapter contains the book's most distinctive idea: you become a better programmer the way writers become better writers, by reading good work. Most programming books show you snippets written for the occasion. This one takes you on a walk through real, respected open-source projects and points out what makes them good.

The chapter moves through several open-source codebases, among them Reitz's own Requests and Tablib and the web framework Flask, and draws attention to their structure, style and design choices: short functions, clear names, modules used sensibly. Requests is the showcase for what Reitz calls design "for humans," in which a library's interface is built around what a person naturally wants to do rather than around how the machinery works. The lesson is a skill more than a fact. Learn to open an unfamiliar project, find your way around it, notice the patterns, and carry them back into your own work. The Preface suggests that even casual Python users will get something from this chapter.

Shipping great code

Writing something useful is half the job; getting it into other people's hands is the other half. The sixth chapter untangles the vocabulary of packaging and distribution and lays out the routes: publishing to the public package index, using alternatives such as Conda, running a private package server inside a company, or "freezing" an application into a standalone executable that runs on a machine with no Python installed.

The organizing question is refreshingly simple: who is receiving this? If your audience is other developers, give them a package they can install. If your audience is end users who neither know nor care what Python is, give them a frozen application.

A scenario guide for the rest

Part III, about a hundred pages, changes character. It is a survey of trusted tools organized by the job to be done, in five chapters: user interaction (notebooks, command-line tools, graphical interfaces and web frameworks), code management and improvement (continuous integration, system administration, and making Python faster), software interfaces (web clients and APIs, serialization, networking and cryptography), data manipulation (the scientific stack, text and image processing) and data persistence (file formats and databases). These chapters are annotated lists rather than lessons. You do not read them so much as consult them, when you face a new kind of task and want to know where the community would start. An appendix adds notes on the Python community and how it governs itself, along with reading lists for learners at different levels.

Putting It to Work

• Isolate every project. Give each one its own virtual environment so dependencies never collide.
• Use Python 3. The book recommended it for new work in 2016; today it is the only choice.
• Follow PEP 8 and take the Zen of Python seriously. Readable code is the goal, not clever code.
• Read good code on purpose. Pick a well-regarded open-source project and study how it is organized, named and tested.
• Finish the job. Structure, test, document and license your project as though strangers will depend on it.
• Match the packaging to the audience. A package for developers; a frozen application for end users.
• Don't reinvent the wheel. Reach for the libraries the community already trusts, and follow the book's links when you need depth.

A word on expectations, because readers are divided. On Goodreads the book averages just under four stars: solidly liked, not adored. Fans call it a practical, no-fluff overview of the whole Python landscape and praise its links; one reviewer said it taught them things they did not know they did not know. Critics point out that it is shallow by design, that it adds little to the free website it came from, and that despite the publisher's "Beginner" label it is uneven and harder going than a true beginner would expect. It is also a snapshot of 2016, and some tool recommendations have aged.

Who Should Read It

This is for the programmer who has learned Python's basics and now wants to know how the professionals do it. The Preface names its audience as new to mid-level Python programmers who want to contribute to open source, start a career or build a company with the language. If that is you, and you would like a friendly, opinionated tour of the ecosystem in one sitting, it will save you a great deal of wandering. Complete beginners should learn the language first, and anyone who wants the freshest advice should know that the living online guide is free.

This has been a summary of The Hitchhiker's Guide to Python by Kenneth Reitz and Tanya Schlusser, giving you the GIST so you can decide if you want the REST.