Frustrations without static types

Recently I was working on a piece of my company’s Python code base that I hadn’t touched before. It was part of an automation script that makes some API calls to GitHub using the Requests library.

I needed to check some of the parameters on the response, run some different functions based on the response code and various other checks. But without static types, there was no easy way to know exactly what parameters the response object had. Surely it had a status code of some kind right? But was it:

• response.code
• response.status
• response.statusCode
• response.status_code
• response.statuscode

Without static types there was no easy way for me to know. Even if I happened to remember that for this specific library the answer is response.status_code, is it a number? Is it a string? What about other values on the response? In order to figure all this out, I had to dig into the docs and source code of the requests library.

Python has a lot of benefits, and I use it daily, but static typing is not definitely not one of them. With one of any of the many statically typed languages and a decent IDE or text editor, I would have been able to write the checks that I needed without having to do any external investigation. In my spare time I’ve been working on a little bit of Go, and the presence of static types is a breath of fresh air from the Python that I write at work, and the JavaScript that I used at my previous job.

Clearly static types are not the only thing to consider when picking a language, but this is a clear, albeit simple, example of some frustrations of when you don’t have them.

Written by James Quigley, an SRE/DevOps Engineer, and general tech nerd. Views and opinions are my own. Check out my YouTube Channel or follow me on Twitter!