A Python Walkabout – Episode 1

I recently decided to expand my language skills and learn Python properly. I had dabbled in it at a previous job, but that was long ago and very little of that knowledge has survived in my head. I figured an online course of some sort was the best way to go. I bought a Python boot camp to learn the basics of the language, but it was going slower than I wanted. It’s geared for absolute beginners and I now realize I should have tried to find one suited for experienced developers. In any case, I decided to start setting up an actual working codebase for what I want to write: the new back end web service for the Music Browser.

Which brings us to this post: the first in a series of things I’ve learned about the language, the Python toolchain, how stuff works, and how to do things the right way. Obviously for experienced Python devs none of this is new. But I figured having a reference to read later would be useful. I plan to add more entries as I go. Here’s the first topic:

Choice of Framework

My goal was to create a RESTful web service, so my first question was how is that done in modern Python. There are currently two main types of framework to use: one that is WSGI-based or ASGI-based. It’s job is to be a bridge between a Python service and the underlying HTTP server. The first one is the legacy standard that has been around for a while. It’s biggest drawback is it responds to HTTP requests synchronously. The second one is the modern version that does the same thing and is backwards-compatible, but can respond to requests asynchronously, providing better performance. It also includes other features that are useful in building full-featured services.

The most popular WSGI framework is flask. It’s battle-tested, has a lot of documentation and examples, and is simple to set up and use. For an ASGI framework there are several choices, such as FastAPI. I went back and forth over which I should use. Part of me wanted to pick flask since it’s easier to configure out of the box and I could spin up something quickly. But another part of me wanted to go with the current thing, since I should try to learn the future and not the past. Plus the idea of having async support by default was appealing.

In the end flask won out. I wanted to get some working code going ASAP, and I was worried I’d spend a ton of time learning the ins and outs of something complex like FastAPI before being able to get an app off the ground. All the docs I read said flask was dead easy to get started.

After that decision came a related next question: what form of flask should I use? Turns out there is no-frills flask, but also other libraries that are extensions to it or drop in replacements for it, which offer a lot of niceties that make writing APIs easier. I looked at a couple and decided on APIFlask. I had a working flask setup with two basic endpoints already, and impulsively started re-factoring things after browsing the APIFlask web site for like 5 minutes (note to self: a bit more deliberation on these kinds of things is worth it. You never know how far you might get in the new shiny thing before realizing it’s just not going to work for you, and I had a brief scare about not being able to figure out how to do a particular thing I wanted to do).