# Writing sharable Python code

Most of us in academia do not have formal training in computer science, yet for many of us writing and sharing code is an essential part of our research. While the quality of code produced by many graduate students can be quite impressive, many of us never learned the basic CS principles that allow programs to be sharable and inheritable by other programmers. Last summer I proctored an online class in Python fundamentals. The course was for beginner programmers and, though it covered material simpler than the scripts I write for my PhD, I learned a lot about how to properly document and structure Python functions to make them usable by others. In this post I’ll discuss two important concepts I took away from this course: writing proper function specifications and enforcing preconditions using assert statements.

## Function Specifications

One of the the most important aspects of writing a quality Python function is proper specification. While the term may sound generic, a specification actually has a very precise definition and implementation for a Python function. In practice, a specification is a docstring, a “string literal” that occurs as the first statement in a function, module, class or method, formed by a bracketed set of “””. Here is an example of a simple function I wrote with a specification:

```
"""
Returns: theta converted to degrees

Value return has type float

Parameter theta: the angle in radians
Precondition: theta is a float
"""
return theta * (180.0/3.14159)
```

The function specification is everything between the sets of “””. When Python sees this docstring at the front of a function definition, it automatically is stored as the “__doc__” associated with the function. With this specification in place, any user that loads this function can access its __doc__ by typing help(radians_to_degrees), which will print the following to the terminal:

```Help on function radians_to_degrees in module __main__:

Returns: theta converted to degrees

Value return has type float

Parameter theta: the angle in radians
Precondition: theta is a float
```

The help function will print anything in the docstring at the start of a function, but a it is good practice for the specification to have the following elements:

1. A one-line summary of the function at the very beginning, if the function is a “fruitful function” (meaning it returns something), this line should tell what it returns. In my example I note that my function returns theta converted to degrees.
2. A more detailed description of the function. In my example this simply provides the type of the return value.
3. A description of the function’s parameter(s)
4. Any preconditions that are necessary for the code to run properly (more on this later)

I should note that officially the Python programming language has a more flexible set of requirements for function specifications, which can be found here, but the attributes above are a good starting point for writing clear specifications.

Properly specifying a Python function will clarify the function’s intended use and provide instructions for how new users can utilize it. It will also help you document your code for formal release if you ever publish it. Google any of your favorite Python functions and you’ll likely be brought to a page that has a fancy looking version of the function’s specification. These pages can be automatically generated by tools such as Spinx that create them right from the function’s definition.

Aside from clarifying and providing instructions for your function, specifications provide a means of creating a chain of accountability for any problems with your code. This chain of accountability is created through precondition statements (element four above). A precondition statement dictates requirements for the function to run properly. Preconditions may specify the type of parameter input (i.e. x is a float) or a general statement about the parameter (x < 0).

For large teams of many developers and users of functions, precondition statements create a chain of accountability for code problems. If the preconditions are violated and a code crashes, then it is the responsibility of the user, who did not use the code properly. On the other hand, if the preconditions were met and the code crashes, it is the responsibility of the developer, who did not properly specify the code.

## Asserting preconditions to catch errors early

One way to improve the usability of a code is to catch precondition violations with statements that throw specific errors. In Python, this may be done using assert statements. Assert statements evaluate a boolean expression and can display a custom error message if the expression returns false. For example, I can modify my radians_to_degrees function with the following assert statement (line 10):

```def radians_to_degrees(theta):
"""
Returns: theta converted to degrees

Value return has type float

Parameter theta: the angle in radians
Precondition: theta is a float
"""
assert type(theta) == float, repr(theta) + ' is not float'
return theta * (180.0/3.14159)
```

A helpful function in my assert statement above is “repr”, which will return a printable representation of a given object (i.e. for a string it will keep the quotation marks around it). Now if I were to enter ‘a’ into my function, I would get the following return:

```AssertionError: 'a' is not float
```

This is trivial for my example, but can save a lot of time when running large and complex functions. Rather than seeing 30 lines of “traceback…”, the user will be immediately brought to the source of the error. In general, you should try to make assert statements as precise as possible to pinpoint the violation.

It’s important to note that not every conceivable precondition violation requires an assert statement. There is a tradeoff between code efficiency and number of assert statements (checking a precondition takes time). Determining which preconditions to strictly enforce with assert statements is a balancing act and will be different for each application. It’s important to remember though, that even if you do not have an assert statement for a precondition, you should still list all preconditions in the function specification to preserve the chain of accountability.

## Further resources

This post concerns specifications for Python functions. However, the use of docstrings is also important when coding modules, classes and public methods. Guidance on how these docstrings may be formatted can be found here.

While this post focused on Python, informative function specifications are important for all programming languages. Some resources on documentation in other languages can be found below:

## 4 thoughts on “Writing sharable Python code”

1. Hugo |

Great post, David. I feel like your first line does drive the point home. It’s odd to think that many of us in academia don’t have any formal training in computer science, yet we rely on the code we write to carry out our research. Reproducibility is one of the pillars of scientifically sound research, but I feel like it’s still a topic poorly explored. I think posts like this will certainly find an audience. I myself would love to collaborate if you’d like to write a post about reproducibility in R.

• David Gold |

Thank you, I’m glad you enjoyed the post! I don’t have too much personal experience with R, I’ve used it for courses, but for the majority of my work I use Python and C++. I have many colleague who use R as their primary tool, so I think it would be a great topic for a future post.

2. Thank you for sharing David. Writing a well documented code is beneficial to the coder as well as those who might inherit the code in the future.