Python for Humanists 3: More Zen and the Historian Programmer

Welcome to the third installment of my Python series! Last time we detailed the IDLE interface and talked about a few of the principles of the Python language through the “Zen of Python” by Tim Peters. This time, we’ll look at a few more lines of the Python philosophy. Here are two great guides through the Zen of Python that I use in this post!

3. Simple is better than complex
 Python is structured to be simple and explicit. If you can program a simple line of code, it is much better than a complex one. This is one reason why you’ll see Python coders constantly finding ways to simplify their code. One quote that is often attributed to this philosophy is by Chris Connell: “Junior programmers create simple solutions for simple problems. Senior programmers create complex solutions to complex problems. Great programmers find simple solutions to complex problems.” For example, when you want to swap values between two variables in JavaScript, you have to:

var a = 5, b = 9;
b -= a; // a = 5, b = 4
a += b; // a = 9, b = 4
b = a - b; // a = 9, b = 5

By contrast, with Python, all you have to do is define the variables – then:

b, a = a, b

Instead of three lines of code, Python allows you to swap variables in one line. This means that the python code is easier to read, understand, and (where necessary) memorize.

4. Complex is better than complicated. While it is inevitable that some programs become complex (because they are performing complex operations), no line of code should ever be complicated (or difficult to understand). Dru Sellers explains this part of Python code with the following example:

Many problems require complexity to solve. Calculating the discounted value for a 30 year financial instrument using a predicted rate model with a monthly granularity requires a lot of work. You have to generate the rate model, calculate the cash flows from the instrument, then apply the discount to the flows. If this seems simple to you its because you understand the reasons behind each one of these steps.

I don’t think any problem requires ‘complicatedness’ in order to be solved. This is like the recurring geek joke, “Well we could call the RateManager and then send the results in a JSON document in an email to the InstumentClass that then faxes the … and finally a suite of monkeys types the result on your screen.” Does your problem need that kind of solution?

5. Flat is better than nested. Those of you who are new to coding might not understand the difference between flat code and nested code. Making your code nested means that you organize your code in layers, in other words, you embed code within other code. In the book Pro Python, Marty Alchin explains that, in nested code, “it’s fairly difficult to follow what’s really going on because the […] nature of [nested] code blocks requires you to keep track of multiple levels of conditions” (4). He gives the following example of nested code:

if x > 0:

if y > 100:

raise ValueError("Value for y is too large.")


return y


if x == 0:

return False


raise ValueError ("Value for x cannot be negative.")

If you don’t nest the code, you get a much easier to read set, as Alchin shows us:

if x > 0 and y > 100

raise ValueError("Value for y is too large.")

elif x > 0

return y

elif x == 0

return False


raise ValueError ("Value for x cannot be negative.")

The second example is much easier to read, since you don’t have to scan multiple levels of code. Don’t worry too much about understanding exactly what this program does at the moment, just note that it is a much simpler formulation than the first example. I’ll continue my way through the Zen of Python in the next installment.

The Programming Historian
Miriam Posner just introduced me to this wonderful resource. It’s an Open-Source guide to programming in Python, written by historians. So you know that it will be applicable to a humanist audience looking to integrate Python into their digital skill set. I really like their over advice for learning PythonYou should be able to put what you learn to work in your research immediately. We think that many beginning programmers lose patience because they can’t see why they’re learning what they’re learning.

  • Digital history requires working with sources on the web. This means that you’re going to be spending most of your research time working in a browser, so you should be able to put your programming skills to work there.
  • You will have to be somewhat polyglot. Individual programming languages can be beautiful objects in their own right, and each embodies a different way of looking at the world. In order to become a good programmer, you will eventually have to master the intricacies of one or more particular languages. When you’re first getting started, however, you need something more like a pidgin.
  • Open source and open access are both good things. We’re providing open access to this book. As we develop it, we’ll be searching for ways to best incorporate the peer review and continual improvement that characterize open source projects. We also build our work on top of other open source projects, particularly PythonFirefoxZotero and the Simile tools.

Check out the guide and try out a few of the exercises. I’m taking next week off in order to celebrate Christmas with my family. I’ll be back after the New Year for another installment!


  1. A simpler version of the javascript ‘swap-variables’ problem would use the standard ‘temp variable’ approach instead:

    var a=5,b=9;
    /* stuff … */
    var c = a; // c=5,a=5,b=9
    a = b; // c=5,a=9,b=9
    b = c; // c=5,a=9,b=5

    The addition/subtraction approach avoids allocating an extra variable, but makes the logic a bit harder to follow, and wouldn’t work as expected for non-numeric values.

    But, you’re certainly right that using the Python idiom “a,b=b,a” is simpler for either case. 🙂

    As a developer, I’d like to suggest that, generally, if extra lines of code makes it easier to understand how the code works, use the extra lines of code! It’s incredibly frustrating to try to reverse-engineer someone else’s code because they were trying to be too clever and would up with some abomination that’s impossible to debug or modify.

    (To be clear, I’m not criticizing the variable-swap example, though, because your “a,b=b,a” example should be a common idiom amongst Python programmers. I’m just saying that minimizing lines-of-code at the expense of readability is a sin )

Leave a Reply