Python for Humanists 3: More Zen and the Historian Programmer

Posted by Roger Whitson on December 20th, 2011

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.")

else

return y

else:

if x == 0:

return False

else:

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

else:

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!

A New Birth of Academic Freedom

Posted by Roger Whitson on August 7th, 2014

My NASSR 2014 Presentation – “@autoblake: Between Critical Making and Computation”

Posted by Roger Whitson on July 8th, 2014

DHSI 2014 Day 1, or Why We Need the MLA Report

Posted by Roger Whitson on June 3rd, 2014

Some #dhsi2014 Essentials

Posted by Roger Whitson on May 25th, 2014

Faculty Letter about Sexual Assault on WSU Campus

Posted by Roger Whitson on May 15th, 2014

Reviewing the Reviewer: Grant Scott’s Review of Blake 2.0: William Blake in Twentieth-Century Art, Music, and Culture.

Posted by Roger Whitson on May 2nd, 2014

On Several Scales of Reals and Realities, Archival or Digital or Otherwise

Posted by Roger Whitson on April 18th, 2014

Day of the Digital Humanities 2014 Videos

Posted by Roger Whitson on April 8th, 2014