How to Make Mistakes in Python

Introduction

To err is human; to really foul things up requires a computer.

Bill Vaughan

I started programming with Python in 2000, at the very tail end of The Bubble. In that time, I’ve…done things. Things I’m not proud of. Some of them simple, some of them profound, all with good intentions. Mistakes, as they say, have been made. Some have been costly, many of them embarrassing. By talking about them, by investigating them, by peeling them back layer by layer, I hope to save you some of the toe-stubbing and face-palming that I’ve caused myself.

As I’ve reflected on the kinds of errors I’ve made as a Python programmer, I’ve observed that they fall more or less into the categories that are presented here:

Setup

How an incautiously prepared environment has hampered me.

Silly things

The trivial mistakes that waste a disproportionate amount of my energy.

Style

Poor stylistic decisions that impede readability.

Structure

Assembling code in ways that make change more difficult.

Surprises

Those sudden shocking mysteries that only time can turn from OMG to LOL.

There are a couple of quick things that should be addressed before we get started.

First, this work does not aim to be an exhaustive reference on potential programming pitfalls—it would have to be much, much longer, and would probably never be complete—but strives instead to be a meaningful tour of the “greatest hits” of my sins.

My experiences are largely based on working with real-world but closed-source code; though authentic examples are used where possible, code samples that appear here may be abstracted and hyperbolized for effect, with variable names changed to protect the innocent. They may also refer to undefined variables or functions. Code samples make liberal use of the ellipsis (…) to gloss over reams of code that would otherwise obscure the point of the discussion. Examples from real-world code may contain more flaws than those under direct examination.

Due to formatting constraints, some sample code that’s described as “one line” may appear on more than one line; I humbly ask the use of your imagination in such cases.

Code examples in this book are written for Python 2, though the concepts under consideration are relevant to Python 3 and likely far beyond.

Thanks are due to Heather Scherer, who coordinated this project; to Leonardo Alemeida, Allen Downey, and Stuart Williams, who provided valuable feedback; to Kristen Brown and Sonia Saruba, who helped tidy everything up; and especially to editor Meghan Blanchette, who picked my weird idea over all of the safe ones and encouraged me to run with it.

Finally, though the material discussed here is rooted in my professional life, it should not be construed as representing the current state of the applications I work with. Rather, it’s drawn from over 15 years (an eternity on the web!) and much has changed in that time. I’m deeply grateful to my workplace for the opportunity to make mistakes, to grow as a programmer, and to share what I’ve learned along the way.

With any luck, after reading this you will be in a position to make a more interesting caliber of mistake: with an awareness of what can go wrong, and how to avoid it, you will be freed to make the exciting, messy, significant sorts of mistakes that push the art of programming, or the domain of your work, forward.

I’m eager to see what kind of trouble you’ll get up to.