Lesson 16: Python style¶

This lesson was generated from a Jupyter notebook. You can download the notebook here.

import numpy as np

This lesson is all about style. Style in the general sense of the word is very important. It can have a big effect on how people interact with a program or software. As an example, we can look at the style of data presentation.

The Keeling curve is a measure of the carbon dioxide concentration on top of Muana Loa over time. Let's look at a plot of the Keeling curve.

I contend that this plot is horrible looking. The green color is hard to see. The dashed curve is difficult to interpret. We do not know when the measurements were made. The grid lines are obtrusive. Awful.

Lest you think this plot is a ridiculous way of showing the data, I can tell you I have seen plots just like this in the literature. Now, let's look at a nicer plot.

Here, it is clear when the measurements were made. The data are clearly visible. The grid lines are not obtrusive. It is generally pleasing to the eye. As a result, the data are easier to interpret. Style matters!

(We will talk about how to make beautiful plots like the one here later in the bootcamp.)

The same arguments about style are true for code. Style matters! We already discussed how important documentation is, but having a well-defined style also helps keep your code clean, easy to read, and therefore easier to debug and share.

PEP 8¶

Guido van Rossum is the benevolent dictator for life (BDFL) of Python. He invented Python, and he ultimately decides what happens with the language. To get new features or other enhancements into the language, Guido either writes or (usually) considers a Python Enhancement Proposal, or a PEP. Each PEP is carefully reviewed, and often there are many iterations with the PEP's author(s). Ultimately, Guido decides if the PEP becomes part of the Python language.

Perhaps the best-known PEPs are PEP 8 and PEP 20. This lesson is about PEP 8, but we'll pause for a moment to look at PEP 20 to understand why PEP 8 is important. PEP 20 is "The Zen of Python." You can see its text by running import this.

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

These are good ideas for coding practice in general. Importantly, beautiful, simple, readable code is a goal of a programmer. That's where PEP 8 comes in. PEP8 is the Python Style Guide, written by Guido, Barry Warsaw, and Nick Coghlan. You can read its full text in the Python PEP index, and I recommend you do that. I also recommend you follow everything it says! It helps you a lot. Trust me; my life got much better after I started following PEP 8's rules.

Note, though, that your code will work just fine if you break PEP 8's rules. In fact, some companies have their own style guides. Google's style, for example, is different than PEP 8. And they even hired Guido after PEP 8 was released (though he now works for Dropbox)!

Key points of PEP 8¶

PEP 8 is extensive, but here are some key points for you to keep in mind as you are being style-conscious.

Variable names need to be descriptive.
Variable names are all lower case with underscores separating words.
Do not name varibales l, O, or I because they are hard to distinguish from ones and zeros.
Function names are lower case and may use underscores.
Class names are in CamelCase. (We are not explicitly covering classes in the bootcamp, though we did in the past. You will come across CamelCase objects in other packages, which usually means you are instantiating a class.)
Module names are short and lower case. Underscores should be avoided unless necessary for readability.
Lines are maximally 79 characters long.
Lines in doc strings are maximally 72 characters long.
Avoid in-line comments; put the comment directly above the code.
Avoid excessive comments that state the obvious.
Generally, put single spaces around binary operators, unless omitting space improves readability. For example, x**2 + y**2. Low precedence operators should have space.
Assignment operators should always have single spaces around them except when in keyword arguments. E.g., no space in f(x, y=4).
Put spaces after commas in function definitions and calls. This also applies for lists, tuples, NumPy arrays, etc.
Avoid excessive spaces within parentheses, braces, and brackets.
Use a single blank line to separate logical sections of your code.
Put two blank lines between functions in a .py file.
Put all import statements at the top of the file, importing from one module per line.

Some examples of PEP 8-ified code¶

Let's now look at some examples of code adhering to PEP 8 and code that does not. We'll start with some code we used before to find start codons.

seq='AUCUGUACUAAUGCUCAGCACGACGUACG'
c='AUG'  # This is the start codon
i =0  # Initialize sequence index
while seq[ i : i + 3 ]!=c:
    i+=1

print('The start codon starts at index', i)

The start codon starts at index 10

Compare that to the PEP 8-ified version.

start_codon = 'AUG'

# Initialize sequence index for while loop
i = 0

# Scan sequence until we hit the start codon
while seq[i:i+3] != start_codon:
    i += 1
    
print('The start codon starts at index', i)

The start codon starts at index 10

The descriptive variable names, the spacing, the appropriate comments all make it much more readable.

Here's another example, the dictionary mapping single-letter residue symbols to the three-letter equivalents.

aa = { 'A' : 'Ala' , 'R' : 'Arg' , 'N' : 'Asn' , 'D' : 'Asp' , 'C' : 'Cys' , 'Q' : 'Gln' , 'E' : 'Glu' , 'G' : 'Gly' , 'H' : 'His' , 'I' : 'Ile' , 'L' : 'Leu' , 'K' : 'Lys' , 'M' : 'Met' , 'F' : 'Phe' , 'P' : 'Pro' , 'S' : 'Ser' , 'T' : 'Thr' , 'W' : 'Trp' , 'Y' : 'Tyr' , 'V' : 'Val' }

My god, that is awful. The PEP 8 version, where we break lines to make things clear, is so much more readable.

aa = {'A': 'Ala',
      'R': 'Arg',
      'N': 'Asn',
      'D': 'Asp',
      'C': 'Cys',
      'Q': 'Gln',
      'E': 'Glu',
      'G': 'Gly',
      'H': 'His',
      'I': 'Ile',
      'L': 'Leu',
      'K': 'Lys',
      'M': 'Met',
      'F': 'Phe',
      'P': 'Pro',
      'S': 'Ser',
      'T': 'Thr',
      'W': 'Trp',
      'Y': 'Tyr',
      'V': 'Val'}

For a final example, consider the quadratic formula.

def qf(a, b, c):
    return -(b-np.sqrt(b**2-4*a*c))/2/a, (-b-np.sqrt(b**2-4*a*c))/2/a

It works just fine.

qf(2, -3, -9)

(3.0, -1.5)

But it is illegible. Let's do a PEP 8-ified version.

def quadratic_roots(a, b, c):
    """Real roots of a second order polynomial."""
    
    # Compute square root of the discriminant
    sqrt_disc = np.sqrt(b**2 - 4*a*c)
    
    # Compute two roots
    root_1 = (-b + sqrt_disc) / (2*a)
    root_2 = (-b - sqrt_disc) / (2*a)

    return root_1, root_2

And this also works!

quadratic_roots(2, -3, -9)

(3.0, -1.5)

This is really important.¶

I want to reiterate how important this is. Most programmers follow these rules closely, but most scientists do not. I can't tell you how many software packages written by scientists that I have encountered and found to be almost completely unreadable. Many of your colleagues will pay little attention to style. You should.