Juha-Matti Santala - Community Builder. Dreamer. Adventurer.

Y is for YAGNI - Python A to Z

2026-08-28T00:00:00Z

Python A-Z is a blog series about Python. Each day, I share insights, ideas and examples for different parts of Python development that match with the letter of the day. Blaugust is an annual blogging festival in August where the goal is to write a blog post every day of the month.

While I like writing code to solve my technical problems and fulfill my software needs, I don’t like writing unnecessary code. Writing something because you thought it could be useful is often — unless you learned something from it — wasteful in terms of time and effort and added complexity.

YAGNI (You aren’t gonna need it) is a principle that arose from extreme programming methodology. While I have never worked in a project or company that followed any specific methodology to the letter, this one has been fundamental in my understanding of how to build software in a smart way. It hasn’t been without its faults though: one of my jobs ended due to a big clash with management around this idea.

The principle isn’t only helpful in focusing on what to do and by extent, saving money by not spending time and money on unnecessary things, it also brings about other positive effects. it’s not only about code we write but features we design.

Code you write stays simpler because less assumptions about future are introduced early. If you write code that is easy to extend and modify, you don’t need to prepare for every potential use case from day 1.

When it comes to designing software for its users (even if that’s just yourself), building something before you have a clear need for it and idea of how it needs to work, can lead to functionality that doesn’t match the expectations and can become more difficult to change in the future to match the actual expectations.

Remember, there’s always someone who depends on already implemented workflows:

I have so often — both in commercial context and my one-user hobby projects — encountered a situation where we think something needs to be built in a specific way. Only to then build it and later learn from actual user(s) using it that it doesn’t fit the need at all or that (almost) nobody uses it.

X is for XML parsing - Python A to Z

2026-08-27T00:00:00Z

Today I’m doing a bit of piggybacking: XML fits the “X” of the day but I’m also going to talk about HTML parsing because we can use the same tool. I’m also cheating a bit (honestly, I couldn’t come up with a new thing starting with X to write about) because I’ll mostly just point you towards my previous work. I’m doing this to bring new eyes to BeautifulSoup as my old blog posts don’t pop up so often in the feeds.

I’m starting with a story time:

It’s probably one of the things I’ve written and spoken more about than anything else: parsing these formats with BeautifulSoup. My first ever developer conference talk was in PyCon Finland 2016 where I came with two slides: opening and closing and a demo without a backup that was using a live website in the Internet. Looking back now, I’m slightly happy I didn’t know better because there were so many things I would now be super stressed out but didn’t realise back then. Luckily, the demo went well. I haven’t dared to rewatch it in years though.

BeautifulSoup describes itself by saying

Beautiful Soup is a Python library for pulling data out of HTML and XML files. It works with your favorite parser to provide idiomatic ways of navigating, searching, and modifying the parse tree. It commonly saves programmers hours or days of work.

I wrote about it six years ago and not a ton has changed to be honest.

One thing I didn’t write about six years ago that I use all the time now is select that allows directly querying with CSS selectors.

Parsing HTML

I’m borrowing the examples from documentation.

We have a simple HTML doc with a couple of paragraphs and links.

html_doc = """
<html><head><title>The Dormouse's story</title></head>
<body>
<p class="title"><b>The Dormouse's story</b></p>

<p class="story">Once upon a time there were three little sisters; and their names were
<a href="http://example.com/elsie" class="sister" id="link1">Elsie</a>,
<a href="http://example.com/lacie" class="sister" id="link2">Lacie</a> and
<a href="http://example.com/tillie" class="sister" id="link3">Tillie</a>;
and they lived at the bottom of a well.</p>

<p class="story">...</p>
"""

To parse that, we do

from bs4 import BeautifulSoup

soup = BeautifulSoup(html_doc, 'html.parser')

We can then start querying into soup with select :

soup.select("title") # [<title>The Dormouse's story</title>]
soup.select("p > a")
# [<a class="sister" href="http://example.com/elsie" id="link1">Elsie</a>,
#  <a class="sister" href="http://example.com/lacie"  id="link2">Lacie</a>,
#  <a class="sister" href="http://example.com/tillie" id="link3">Tillie</a>]

soup.select('a[href$="tillie"]')
# [<a class="sister" href="http://example.com/tillie" id="link3">Tillie</a>]

If you have done frontend development and are familiar with CSS selectors, this is a really nice way compared to traversing the tree manually step by step.

Parsing XML

The same selectors work with XML documents. To test it out, let’s take a look at my RSS feed (I redacted the actual content of the blog posts for brevity):

xml_doc = """<feed>
<title>
Juha-Matti Santala - Community Builder. Dreamer. Adventurer.
</title>
<subtitle/>
<link href="" rel="self"/>
<link href="https://hamatti.org"/>
<updated>2026-08-26T00:00:00Z</updated>
<id/>
<author>
<name>Juha-Matti Santala</name>
<email>juhis@hamatti.org</email>
</author>
<entry>
<title>W is for walrus operator - Python A to Z</title>
<link href="https://hamatti.org/posts/w-is-for-walrus-operator-python-a-to-z/"/>
<updated>2026-08-26T00:00:00Z</updated>
<id>
https://hamatti.org/posts/w-is-for-walrus-operator-python-a-to-z/
</id>
<content type="html">
[ redacted for brevity ]
</content>
</entry>
<entry>
<title>V is for visible characters - Python A to Z</title>
<link href="https://hamatti.org/posts/v-is-for-visible-characters-python-a-to-z/"/>
<updated>2026-08-25T00:00:00Z</updated>
<id>
https://hamatti.org/posts/v-is-for-visible-characters-python-a-to-z/
</id>
<content type="html">
[ redacted for brevity ]
</content>
</entry>"""

To explore the XML document with CSS selectors:

from bs4 import BeautifulSoup
# You also need lxml installed to project

soup = BeautifulSoup(xml_doc, "lxml")

soup.select('author')
# [<author>
# <name>Juha-Matti Santala</name>
# <email>juhis@hamatti.org</email>
# </author>]

soup.select('entry id')
# [
# <id>https://hamatti.org/posts/w-is-for-walrus-operator-python-a-to-z/ </id>, 
# <id>https://hamatti.org/posts/v-is-for-visible-characters-python-a-to-z/ </id>
# ]

W is for walrus operator - Python A to Z

2026-08-26T00:00:00Z

Often in programming we end up in a situation where we want to check for an output of a function and then do something to it if it’s truthy.

if get_next_step() is not None:
	execute(get_next_step())

To avoid calling the function twice and saving computing cycles, we would then call it first, save it and test against it:

next_step = get_next_step()
if next_step is not None:
  execute(next_step)

In Python 3.8, we got an assignment operator (:=), nicknamed walrus operator because it looks like a cute walrus. It lets us shortcut this with

if (next_step := get_next_step()) is not None:
  execute(next_step)

It’s also handy in loops

while (next_step := get_next_step()) is not None:
  execute(next_step)

Now we skip two assignments: one before the loop for initial check and another at the end of the loop for next check.

It’s a great example of relatively small syntax thing that makes the code cleaner and easier to follow and less error prone.

V is for visible characters - Python A to Z

2026-08-25T00:00:00Z

I recently built a website to display my Pokédex Binder. I have a physical binder where I collect Pokémon TCG cards in a way where I aim to have one card for each Pokémon and their regional variants (and some forms when applicable).

For each card, I can write a short note to tell why it’s in my binder.

Here’s an example of my most recent addition: an Onix card that’s signed by all the players in our recent retro tournament where I finished 2nd.

The box has limited size so I need a way to control that in data entry: it should tell me when I’ve written too much. At the same time, I want to allow myself to use Markdown to add formatting and links so I can’t simply count the characters of the input.

I needed a way to count the characters that a user actually sees in the final note box. To justify this as an entry for the V day, I’m calling those “visible characters”.

I asked around in Mastodon and found two solutions.

The first solution, that I ended up using is strip-markdown library.

import strip_markdown

MAX_NOTE_LENGTH = 205

def is_valid_length(note: str) -> bool:
	visible = strip_markdown.strip_markdown(note)
	return len(visible) < 205

for card in pokedex:
  if not is_valid_length(card.note):
    raise ValueError(f'{card.id} has too long note.'
  
  add_to_binder(card) # imagine it exists

A bit later, Jan-Erik shared his solution which uses Python-Markdown:

from markdown import Markdown
from io import StringIO

def unmark_element(element, stream=None):
    if stream is None:
        stream = StringIO()
    if element.text:
        stream.write(element.text)
    for sub in element:
        unmark_element(sub, stream)
    if element.tail:
        stream.write(element.tail)
    return stream.getvalue()

Markdown.output_formats["plain"] = unmark_element

__md = Markdown(output_format="plain")
__md.stripTopLevelTags = False

def strip_markdown(text):
    return __md.convert(text)

U is for uv - Python A to Z

2026-08-24T00:00:00Z

uv is a Python package and project manager but in my day-to-day use it’s more of a script and improved REPL runner. In Tame your pesky little scripts, I wrote about my methods for dealing with different scripts I run from a command line and for the ones I write in Python, I use uv to make them easy to run with dependencies.

For example, the following script saved as soup

#!/usr/bin/env -S uv run --quiet --script

# /// script
# requires-python = ">=3.10"
# dependencies = [
#    "bs4",
# ]
# ///

from bs4 import BeautifulSoup

soup = BeautifulSoup('<ul><li>First</li><li>Second</li></ul>')

can be ran with ./soup and uv will take care of installing BeautifulSoup into a virtual environment that it will run this script in and I can import it into a script. I really like that.

I can also include external dependencies to my REPL sessions with

uv run --with bs4 python
>>> from bs4 import BeautifulSoup
>>> soup = BeautifulSoup('<ul><li>First</li><li>Second</li></ul>')

or I can run a script with a specific Python version with

uv run --python 3.12 script.py

This can be handy if you need to run with a specific version that you don’t default to. Sometimes I run stuff with older versions for example to make sure they work with a specific version or I run stuff with a newer version to test what’s coming in the future.

I’m not particularly excited about the future of uv now that OpenAI acquired it. But for now, it still seems to be a useful tool.

Reply to Dale’s comment on my IndieWeb post

2026-08-24T00:00:00Z

Yesterday, I shared my article There’s no membership card for IndieWeb and got the following comment from Dale:

Great article, I agree 99%.

I do take issue, however, with your spiel that the IndieWeb is a recursive effort to ultimately converge everybody towards a set of ideas. I think it extremely important to the definition of an independent web that people can overtly diverge from the direction of the herd: be creative outside the box, be innovative, and, most of all, be brave and ground-breaking. Only then can the indie web grow and expand its boundaries.

My own definition of a personal web site is one on which one person has the agency to do anything at all with the site without recourse to others. That does not preclude use of such systems as Wordpress, on proviso that the person using such system could in principle move off it--effectively being able to break the walls.
https://khleedril.org/blog/comment/xclloh.html

We don’t disagree here at all.

I don’t think IndieWeb is “a recursive effort to ultimately converge everybody towards a set of ideas”. I apologise if my communication was lacking on that part. First of all, I don’t think everybody is the target of IndieWeb. I’m not even sure if I agree with the “converge [ - - ] towards a set of ideas part”. To encourage an adoption of certain ideas, sure. But not converge in a sense that these would be the only right things.

I also don’t think that the ideas or principles shared within IndieWeb community should be in any way a limiting set of ideas. Being creative outside the box and doing what you want for your site is exactly what I wish people do. I think IndieWeb — with its current definition, the definition that Belvadi proposed or the ideas I shared — encourages that a lot. IndieWeb is all about building new things. All I’m proposing is that we lower the floor of requirements even more than what it is by transforming the idea from a community to set of ideas.

As I wrote in my original post that I referenced, I made the case that it’s very difficult to draw a specific line on what is “IndieWeb enough” and mentioned:

I want IndieWeb to be and to remain an open community where people can decide to be part of, regardless of how their website is built or hosted. I want the community to be inspiring and aspirational with its ideas and technical possibilities rather than limiting or gatekeeping.

I have no problem with someone hosting their site on WordPress being part of IndieWeb. Zero.

I do however want to specify something. You mentioned “definition of a personal web site” while I was specifically speaking of a subset of the community that we call IndieWeb. I don’t think every site — even personal site — needs to have anything to do with IndieWeb ideas to be valid or accepted in the web.

I feel like my point is exactly in line with what you commented: I don’t think there should be any requirements to fulfill or a checklist to fill before you’re “in”.

There’s no membership card for IndieWeb

2026-08-23T00:00:00Z

Blaugust is an annual blogging festival in August where the goal is to write a blog post every day of the month.

My good internet friend V.H. Belvadi — whose writing always gets my mind excited with his writing — published a great piece on his ideas on re-defining the IndieWeb and I have like half a dozen threads of ideas that sparked from that post. Here’s my first one.

He hosted IndieWeb Carnival last December where a lot of people wrote about their ideas for where IndieWeb is going towards in the next five years. In this post, he takes a look at how IndieWeb movement defines itself and offers his thoughts on some of the issues in that and how he would define it.

While this blog post was inspired by his post, don’t consider this as any kind of rebuttal. There are some points where I point directly to his writing but everything else is just generally my ideas around the topic.

The starting point that Belvadi also quotes is this definition from IndieWeb wiki:

The IndieWeb is a community of independent and personal websites based on the principles of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.

A note on the tech club

In my entry from December, one of the things I said about IndieWeb was:

I’m a technical person and I love building my own tools and tinkering with stuff on Saturday evenings. For me, IndieWeb is a community that encourages that and helps me find other people who care about the same things.

I want to clear up something around that since it was commented on by some people in their blog posts between December and now and as this blog post today is not considering this aspect at all so it might seem contrary.

For me — at least for a long time, I’m not sure how strongly I hold that idea anymore for practical reasons that I’ll go to later — IndieWeb presented as a community of builders who like to tinker and make things and indie/personal/open/small web was a movement that was all about personal websites, separation from corporate controlled environments and all that.

That’s why I don’t consider that view as gatekeeping. The indie web is the important movement that I think we shouldn’t gatekeep. At the same time, I think it’s okay and valuable to have a community for people who like to tinker and build stuff.

And crucially importantly:

It’s more of a mindset than a skill check.

That being said, let’s get to this post’s actual point.

There shouldn’t be a membership card

The title of this blog post is more of my desire than the state of the world right now — depending maybe on whose definition you take to heart.

Coming back to Belvadi’s essay, he starts by pondering how we should reach a definition and if we should do it in inclusionary (what it is) or exclusionary (what it is not) terms.

Should the definition be inclusionary or exclusionary? Some, like Khürt Williams, are especially opposed to the exclusionary definition or what they call ‘Defining yourself by your enemy.’ Others, the majority by a cursory assessment, seem to define the IndieWeb specifically by contrasting its features with that of the CorpoWeb.

I think the exclusionary is the easy way to convey the message to someone who is currently running their online presence in walled, controlled platforms like Facebook, Instagram, X and TikTok. It doesn’t go much further than that in my opinion though.

I don’t think i necessarily disagree with Belvadi with the definition he lands to. He makes great points at dissecting the IndieWeb wiki’s description for potential inaccuracies and issues and proposes new definitions. But I want to approach it from a very different perspective than what he wrote.

I think the problem with both the IndieWeb wiki definition and Belvadi’s new definition is that they seem to focus on “milestones” or checkboxes you need to fulfill to be consider part of the IndieWeb.

For the wiki’s definition, those are owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content. There are also a lot of other things people in the community like to talk about like microformats and webmentions that many people feel too much gatekeeping or too technical and that people should chill out.

Belvadi’s definition

The IndieWeb is a space comprising websites whose domain ownership and organisational, operational and editorial sovereignty remain with an individual or non-corporate group of individuals, free from external obligations that compromise that sovereignty

talks about ownership, sovereignty and obligations.

One thing I want to focus on and that I strongly agree is when he said

So what is the IndieWeb? I do not believe the IndieWeb is a community.

Even though I use the word community often with IndieWeb to talk about the people who gather together around it, I think the biggest value in IndieWeb is not a membership of such community. There are no membership cards and thus, there should not be membership requirements.

I think IndieWeb should be a set of ideas to work towards. How many of them you fill? Doesn’t matter. Doesn’t make you or your website more or less “IndieWeb”. I don’t think there should be any checklist we go through to assess whether someone belongs or not.

We should focus on sharing and discussing ideas and help build tools so that more people who want to implement them (for any reason they want), can do so.

It’s a iterative journey

A strict definition that excludes a lot of people who could be "almost matching" leads to never getting those people in because you need to fill all the requirements before you're part of the group and the steps to get there can be too much to do at once.

I’ve had a website in the web for about 25 years by now. All of its iterations have been indie web but for some part of that 25 years, I didn’t have a domain or didn’t POSSE (Publish (on your) Own Site, Syndicate Elsewhere) or didn’t have webmentions or microformats.

Bobby Hiltz in his carnival entry in December wrote

I was pulled into the IndieWeb through Mastodon. I saw people talking about Gemini and had some free time and an extra Raspberry Pi, so I set it up. Then I figured that I could also host a regular static site. I thought it was great to own the words I was sharing and have them as physical files on my computer. Not having an account on some site (WordPress or Blogger) was a contributing factor, being able to ask people on the Internet to help me sort things out was a bonus.

It’s a journey of many small steps. I don’t want us to turn people back when they first learn about IndieWeb ideas because they do not fulfill all the requirements for the non-existent membership.

Too strict requirements can be harmful to the goal. If we want people to start doing more sports to become healthier, it's not a great idea to have tryouts with minimum fitness requirements. If we want people to build more open, personal websites, we don't want there to be requirements for people to join the community so they can start learning how to do that.

In a blog post that has disappeared from the web, someone — let’s call them J — considered it too much work to "set up POSSEing, microformats, webmentions and comments.” They wrote about how they want to be part of the indie web rather than IndieWeb and I can’t fault them for that.

When I first got interested in IndieWeb, I landed on a web page (that I can’t find anymore, maybe for the better) that presented IndieWeb as different levels of maturity. It was such a big turn off for me that I built a bit of resentment for the entire idea and spoke about the difference between indie web and IndieWeb and how the first is what matters more. I still hold that idea but I have found a lovely group of people through the latter as well.

IndieWeb of principles rather than requirements

My favourite part of the IndieWeb wiki is the 11 principles.

The IndieWeb Community is largely based on principles that we practice and aspire to [- -].

I like the “aspire to” part. It’s not a checklist of requirements. It’s a list of ideas that we aspire to do: how many or how well you do them is up to you and not the important part.

I like them so much that I have written my own post about them. In it, I note:

Rather than being a binary yes / no categorisation, IndieWeb is a spectrum of many things where you can decide for yourself which one you care about and how much. There’s no point in evaluating anyone’s rate of participation or pointing fingers to “but you post on social media so you’re not really indie”.

If you have a website or want to have one, I recommend you to check out what ideas and tools float around the IndieWeb: the wiki, the Carnival (I love it!) and forums and social media discussions.

Don’t worry about if you’re “IndieWeb enough”. I’m giving you a permission to consider yourself part of the community. There are many ideas that are great. There are some ideas that I don’t particularly subscribe to but that’s fine, others can build them on their sites.

T is for time-machine - Python A to Z

2026-08-22T00:00:00Z

Quite a lot of our software has code in it that deals with time: either by displaying some time (current time, creation/modification time, countdowns etc.) or by doing different logic based on the current time (”show this for the week leading into Christmas” type of deal).

Time is wibbly wobbly — as my favourite Doctor would say — and when writing tests, it means that we need tools to control time. If we let tests run against the system clock, they will fail sometimes and succeed other times. That doesn’t make them very good tests.

Adam Johnson’s time-machine is a lovely library with a great logo to do exactly that (and fast as well).

The interface is nice and simple. A decorator lets you travel to a specific time per function/test:

import datetime
import time_machine

# The first argument is the time to travel to
# tick defines if time should continue moving (True)
# or be frozen (False)
@time_machine.travel('2020-03-10', tick=False)
def test_a_good_day():
	assert datetime.date.today().isoformat() == '2020-03-10'

S is for slicing - Python A to Z

2026-08-21T00:00:00Z

Another 101 level primer day! Today, I write about slicing lists. Python has a very nice syntax for it, albeit one that can take a bit to get comfortable with.

Let’s start with index access

To access a single item in a list, you use [i] where i is the index:

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']

print(pokemon[0]) # Pikachu
print(pokemon[1]) # Snorlax
print(pokemon[2]) # Bulbasaur

If you’re new to programming, it’s important to note that the indexing starts at 0, not 1. This is common for a lot of programming languages but not universal.

If you try to access an index that is larger than the last available index, you’ll run into an IndexError :

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']
print(pokemon[4]) # IndexError: list index out of range

If you use a negative index, Python will count from the end:

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']

print(pokemon[-1]) # Bulbasaur
print(pokemon[-2]) # Snorlax
print(pokemon[-3]) # Pikachu
print(pokemon[-4]) # IndexError: list index out of range

Here, the last element is at index -1 and the first one at 0 - len(pokemon) .

Slicing

“Slicing” refers to accessing a sublist from a list rather than an individual element.

The syntax has three parts, all optional:

list[start:stop:step]

For example, we can create a new list that has all but the first element:

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']
first = pokemon[0] # 'Pikachu'
rest = pokemon[1:] # ['Snorlax', 'Bulbasaur']

# is same as 
rest = pokemon[1:3]

Slicing a list does not change the original! It creates a new copy with the elements we want.

As you can see in the example, the parameters of a slice are optional. If we want everything until the end, we can leave out stop. If we want everything from the start, we can leave out start:

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']
all_but_last = pokemon[:2] # pokemon = ['Pikachu', 'Snorlax']

# is same as 
all_but_last = pokemon[0:2]

The stop parameter is exclusive, meaning we don’t include it.

Since both of them are optional, we can create a copy of a list with

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']
a_copy = pokemon[:] 
print(a_copy) # ['Pikachu', 'Snorlax', 'Bulbasaur']

This will slice everything from the beginning to the end of a list.

We can use negative indices here as well:

pokemon = ['Pikachu', 'Snorlax', 'Bulbasaur']
all_but_last = pokemon[:-1] 
print(all_but_last) # ['Pikachu', 'Snorlax']

The last parameter is step and it allows us to create lists where we skip items or move backwards:

numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

# Take every other element
evens = numbers[::2] # [0, 2, 4, 6, 8, 10]
odds = numbers[1::2] # [1, 3, 5, 7, 9]

# Take every third element
every_third = numbers[::3] # [0, 3, 6, 9]

# Reverse a list
countdown = numbers[::-1] # [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

You can then mix and match these to achieve all sorts of slices.

You can also create slices up front with the built-in slice function:

reverse = slice(None, None, -1)
print(numbers[rev]) # [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

evens = slice(0, None, 2)
print(numbers[evens]) # [0, 2, 4, 6, 8, 10]

I can’t remember a single time I would have used slice but it does help with one of my favourites I’ll repeat many times this month: giving names to ideas is powerful.

No IndexErrors!

A key difference between access by index and slicing is that there are no IndexErrors with slicing.

numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
print(numbers[6:100]) # [6, 7, 8, 9, 10]

When slicing with an end index too large, Python simply goes as far as it can. This can sometimes be a curse and a blessing as you can’t figure out the length of a new list based on the stop parameter.

Use REPL to experiment and learn

Yesterday I wrote about Python’s REPL. It’s really good for learning a new mechanic like this. You can start the REPL and keep on tinkering. Create lists, slice them in any and every way you can imagine and see if the results match your expectations.

R is for REPL - Python A to Z

2026-08-20T00:00:00Z

Completely by accident, I ended up with a four day streak of acronym titles. ORM, PEP, Q and today REPL. We developers sure love acronyms.

REPL (read-eval-print loop) is one of those things that make programming languages more approachable to me. I love being able to build my code bit-by-bit and have an easy way to test ideas out or double check on syntax without having to build all the infrastructure around them to run.

If you start Python without any arguments, you end up in a REPL:

$ python
Python 3.14.6 (main, Jun 23 2026, 15:46:31) [Clang 22.1.3 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

The >>> tells you it is accepting your input and whatever you type there will be executed as Python code.

>>> 2+1
3
>>> print('Hello world!')
Hello world!

You can write practically any Python code in the REPL (I’m not sure if there are some special edge cases). You can define functions, run loops, read files and whatever you need.

It’s not only useful for iterating small parts of code that ends up in your source code. It’s also handy for doing interactive stuff: I often start a Python REPL instead of running commands in zsh shell because I’m so much more comfortable with Python than shell scripting.

Python’s REPL is not quite as good as Clojure’s but if you want a convincing argument for why REPLs are great, check out Ykä’s demo from Aurajoki Overflow showing how good Clojure has it. A lot of it applies to Python as well and is very close to the way I work iteratively with code!

Django shell

Starting a regular REPL in your project is nice for general Python stuff but it’s hard to get the data of your program easily into it. That’s not a problem if you’re building with Django.

By running

$ python manage.py shell
29 objects imported automatically (use -v 2 for details).

Python 3.14.6 (main, Jun 23 2026, 15:46:31) [Clang 22.1.3 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> Card.objects.first()
<Card: Alakazam (1) <base1-1>>

It loads all of your models and urls and stuff into the REPL session and connects to your database so you can immediately start writing queries to tinker with or explore your data.

I practically live in the Django shell when I’m developing my Django projects. Most of the code, before it lands into a source file, starts its life as experiments in the shell. It’s way faster to iterate over ideas and code as the feedback loops is immediate instead of running the full app or tests every time early in the development of a feature.

Debugging Python

When you use breakpoint() to debug your code, you land on a REPL with the context, stack and data of your running program and you can explore it, advance your code and figure out what’s wrong.

To become more efficient in debugging, it’s good to get familiar with REPL usage in general so when you’re in a stressful situation with a bug, you don’t have to focus on learning how to use the interface.

Startup script

Once you get more comfortable with Python, take a look at PYTHONSTARTUP and writing your own startup script. With it, you can run code before the REPL session starts so you can import all the libraries you use all the time (mine starts with ~30 lines of imports for standard library stuff I’m reaching all the time and has a couple of “if installed, import this” imports as well) and set up helper functions.

One super handy tip from mine:

# With these, you can copy-paste JSON into REPL and 
# be considered a valid dictionary
null = None
true = True
false = False

For Django, I also import helpers like Avg, Count, F, Max, Min, Q, Sum and Value if Django is installed as I never remember where they are imported.

All in all, mine is about 350 lines, 90% of which is importing stuff if they exist in the environment.

Another cool trick is defining a pretty printer with some extra syntax.

from pprint import PrettyPrinter

class Printer(PrettyPrinter):
    def __call__(self, *args, **kwargs):
        super().pprint(*args, **kwargs)

    def __truediv__(self, other):
        super().pprint(other)

    def __rtruediv__(self, other):
        super().pprint(other)

    def __repr__(self):
        return repr(pprint)


pp = Printer()
pp.__doc__ = pprint.__doc__

With the __truediv__ , you can do pp/obj where obj is anything and it will pretty print it.

Hugo pointed out that in 3.15, PrettyPrinter gets expand keyword argument:

Add an expand keyword argument for pprint.pprint(), pprint.pformat(), pprint.pp(). If true, the output will be formatted similar to pretty-printed json.dumps() when indent is supplied.

Q is for Q - Python A to Z

2026-08-19T00:00:00Z

Second Django ORM post of the week! First, an important distinction before we start: this blog post is about Django’s Q objects and not about the task queue project Django Q (or its fork Django Q2). Maybe I’ll write about them the next time I need to come up with something for letter Q because that’s not a large pool of ideas.

Basics

Q objects are a way to write Django queries in a more composable way. These two are equivalent in outcome:

from models import Card

Card.objects.filter(name='Bulbasaur')

# and 

from django.db.models import Q

bulbasaur_query = Q(name='Bulbasaur')
Card.objects.filter(bulbasaur_query)

For a simple example like this, there’s not a lot to gain. They are more useful for complex queries. If you want to use multiple fields for lookup, Django combines them with AND operator:

# name = Bulbasaur AND set.name = Mega Evolution
Card.objects.filter(name='Bulbasaur', set__name='Mega Evolution')

With Q objects, we get more logical operators:

name = Q(name='Bulbasaur')
set_name = Q(set__name='Mega Evolution')

name & set_name # AND
name | set_name # OR
name ^ set_name # XOR
~name # NOT

Now, we can combine different queries in many ways that makes it possible to do complex queries while keeping the code more readable and maintainable.

Documentation by giving expressions names

Which brings me to another favourite of mine: documentation.

I really like to give names to implementation details. Rather than reading through code and coming to a complex implementation detail of a query, I can read what it means in the context of the program.

If you run into the following code:

Card.objects.filter(regulation_mark__in=['H', 'I', 'J'])

you’d need to know quite a lot about the details to understand what it does. Sure, you can quickly read that it filters the cards based on their field “regulation mark” being one of “H”, “I” or “J” but what does that mean?

Instead, we can extract the query to a Q object, give it a name and make it reusable across the application (and making it less error prone!):

is_standard_legal = Q(regulation_mark__in=['H', 'I', 'J'])
Card.objects.filter(is_standard_legal)

Now it’s a little bit clearer that this query finds Cards that are legal in the standard format.

This becomes even more valuable when there’s a lot of them. One use case I have for them in my Pokémon TCG toolkit is to combine different pre-determined configurations like format legality as shown above

is_standard_legal = Q(regulation_mark__in=['H', 'I', 'J'])

ace_spec = Subtype.objects.get(type='ACE SPEC')
is_restricted_to_one = Q(subtypes=ace_spec)
is_trainer = Q(supertype='Trainer')

standard_legal_single_trainers = Card.objects.filter(
  is_standard_legal & is_restricted_to_one & is_trainer
)

If you’d only run into the last line, you would have a pretty good idea of what kind of cards we are filtering for. Especially when compared to mental work you need to do to gain the same understanding from:

standard_legal_single_trainers = Card.objects.filter(
  Q(regulation_mark__in=['H', 'I', 'J']) & 
  Q(subtypes=Subtype.objects.get(type='ACE SPEC')) &
  Q(supertype='Trainer')
)

Variables are very good, not only when you need to use them multiple times or in multiple places. I always tell developers, especially the ones newer to the craft, to liberally use intermediate variables to break down their code rather than trying to do too much at once.

It also makes it way easier to debug because you can use those intermediate variables and their values to find where things went wrong.

Giving them good names also helps you understand what you’re trying to achieve and notice logical blunders when the name you give it doesn’t match the effect it has.

Dynamically crafting queries

Like regular queries, Q objects can be crafted dynamically.

# You can start with an empty query!
query = Q()

if set_name:
  query &= Q(set__name=set_name)
  
if supertype:
  query &= Q(supertype=supertype)
  
Card.objects.filter(query)

My project isn’t public but if you want to get an idea for how many search options there are for Pokémon TCG cards, take a look at pkmncards.com’s advanced search page. Q objects make creating these a joy and I can use them everywhere in the app that deals with querying so I can guarantee that my queries are consistent across the app (either all right or all wrong) and need to change them only at one place when I need to fix them or the circumstances change.

P is for Python Enhancement Proposal (PEP) - Python A to Z

2026-08-18T00:00:00Z

PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. The PEP should provide a concise technical specification of the feature and a rationale for the feature. - PEP 1 – PEP Purpose and Guidelines

If you’re a developer, you should start reading PEPs (or equivalents proposals in your language if such exist). They are a wonderful lesson in writing proposals for changes in software, having discussions in good faith between people who have differing opinions and arguing for your viewpoint and recording those discussions into decisions. In your own work or hobby project, this might be done in a form of an architecture decision record (ADR).

My favourite PEPs are a triplet PEP 634 – Structural Pattern Matching: Specification, PEP 635 – Structural Pattern Matching: Motivation and Rationale and PEP 636 – Structural Pattern Matching: Tutorial that defined the pattern matching mechanism that I like a lot.

A PEP starts with a metadata that shows who has authored it, when, what is its status and where you can find the discussion.

Author:
    Tobias Kohn <kohnt at tobiaskohn.ch>, Guido van Rossum <guido at python.org>
BDFL-Delegate:
Discussions-To:
    Python-Dev list
Status:
    Final
Type:
    Informational
Created:
    12-Sep-2020
Python-Version:
    3.10
Post-History:
    22-Oct-2020, 08-Feb-2021
Resolution:
    Python-Committers message

Then, it goes through the motivation for this proposal, rationale, history and context, technical considerations like backwards compatibility and security concerns and a few additional things like references and copyright statement.

These days, the discussion about PEPs happen in Python’s official discussion forum. It’s a joy to read through to see bright minds discuss both the technical and the human side of these proposed changes.

I don’t think I’ll ever be involved in any PEP writing, discussion or decision making. I still enjoy reading them and following their development because it makes me better at arguing for and supporting my ideas and writing better documentation for decisions that have been made.

I encourage you to do the same!

O is for ORM - Python A to Z

2026-08-17T00:00:00Z

Last year when I gave a talk Love Letter to Django in a local meetup, my main thread was about its ORM (Object–relational mapping) and a few things it enables.

I’m a big fan of ORM as a model: abstracting the database layer behind models that model the business logic of your application rather than writing raw SQL at the end of every function call path makes writing program logic way more enjoyable.

Here’s a small excerpt from one of my apps.

from django.db import models
from django.conf import settings

from api.models import Card


class Collection(models.Model):
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
    )

    name = models.CharField(blank=True, null=True)

    def __str__(self):
        if self.name:
            return f"Collection(name={self.name})"
        else:
            return f"Collection(name={self.owner.username}'s collection)"


class CollectionItem(models.Model):
    collection = models.ForeignKey(Collection, on_delete=models.CASCADE)
    variant = models.ForeignKey(CollectionVariant, on_delete=models.CASCADE)
    quantity = models.IntegerField(default=0)

    def __str__(self):
        return f"{self.variant.card}, {self.variant.variant}, x{self.quantity}"

I can then query my collection items in different ways.

## In a view based on the logged in user

def add_to_collection(request, variant_id: str) -> HttpResponse:
  collection = Collection.objects.filter(owner=request.user).first()
  collection_item = CollectionItem.objects.get(
        collection=collection, variant__id=variant_id
  )
  collection_item.quantity += 1
  collection_item.save()
  
  # ... do the rest
  
## In a shell to explore

>>> col = Collection.objects.first()
>>> col.collectionitem_set.all()
<QuerySet [<CollectionItem: Weedle (1) <me4-1>, Normal, x0>, ...]>

It especially helps make new queries easier and lets you focus on the thing you want to achieve rather than diving deep into the database tables and how to make sure everything gets connected correctly every time.

On top of that basic premise, Django’s ORM is so enjoyable and part of it comes down to the REPL shell (guess what I’ll be writing tomorrow for “r”…). The ability to jump on a Django shell and start writing Card.objects.filter(...) to start querying your database and building your software on top of that is something I enjoy a ton.

Joseph Zammit’s talk Thinking in SQL with Django in DjangoDay Copenhagen 2022 improved my understanding of the ORM-SQL relationship a lot and Django Toolbar and Kolo are great tools to debug and understand the queries your application actually makes under the hood and help you identify problems and optimize the queries.

Django’s ORM can be used on a more standalone way as well to connect to query existing databases that are not managed by Django. Paulo Melchiorre has a wonderful blog post about it. You can write a tiny manage.py and run a couple of commands against existing database to create models.py and then start up a Django shell and make queries to explore that database. Really handy when you’re joining a new non-Django project and want a familiar toolset to explore the database.

I know there are people who don’t like ORMs and if you’re one of those people, I invite you to write a rebuttal on your own blog and send me a webmention/email/toot. I genuinely would love to read your thoughts and update this post with links for opposing views.

N is for namedtuple - Python A to Z

2026-08-16T00:00:00Z

If you write any Python code, you should be using more namedtuples than you are using right now. They are my favourite data structure in Python: they are a subclass of tuples so they are immutable but in addition, you give them and their fields names which increases the readability and debuggability of your code a lot.

I have raved about them before: in Batteries included in 2024 as well as every year when writing about Advent of Code. You should read the earlier post for more reasons for why to use them.

For the second time this month, I’ll link to Raymond Hettinger’s great talks, this time to his Beyond PEP 8 talk from PyCon 2015 where in addition to a bunch of other good tips, briefly talks about why namedtuples are better than regular tuples.

They are also a drop-in replacement which makes it easy to start adopting them into an existing codebase without having to do huge rewrites or refactorings. Any function that accepts a tuple, also accepts a namedtuple so whenever you see a tuple being created, you can replace it with a namedtuple and whenever you touch a code that uses those tuples, you can improve the code by changing from index lookups to attribute lookups.

Earlier this week, Adam Johnson shared about a change that’s coming in Python 3.15 where you can no longer use (accidentally supported) keyword argument style for NamedTuple typing.

from typing import NamedTuple

Color = NamedTuple('Color', hue=float, saturation=float, luminosity=float)
# TypeError: NamedTuple() got an unexpected keyword argument 'hue'

It’s been deprecated since 3.13 but if you’ve been using them and have missed the deprecation warnings, now is a really good time to fix it.

Last time I wrote about namedtuples, at least a couple of people told me afterwards that they had taken my praise for them to heart and made improvements to their code so I decided to write about it again this year with hopes that it reaches the eyes of someone who haven’t heard of them before.

Saoirse Ronan Appreciation Week, round 2

2026-08-15T00:00:00Z

Blaugust is an annual blogging festival in August where the goal is to write a blog post every day of the month.

A short Saturday break from my Python series to talk about Saoirse Ronan. She's quickly become one of my favourite actors and after my first Saoirse Ronan Appreciation Week in May, I decided to do another one this week.

Five more days, five more wonderful movies. From historical to artistic and from intense to joyful, there's a lot going on in these five movies.

Monday: How I Live Now

How I Live Now (2013)

6.4/10

3.0/5

66%

Directed by Kevin Macdonald

Starring Saoirse Ronan, George MacKay, Tom Holland

An American girl, sent to the English countryside to stay with relatives, finds love and purpose while fighting for her survival as war envelops the world around her.

First thought after a few first scenes roll by: Saoirse Ronan and Tom Holland are so young in this. From Ronan, I had seen Hanna from her earlier years but my first time seeing Holland was in Marvel's Civil War. Somehow, it's only 3 years later than this but Holland grew up from a boy to a young man in those years. Even at their young age, they both ooze charisma. No wonder they ended up becoming stars.

This movie is quite a rollercoaster ride of moods and tones. It starts with a happy go lucky summer of a group of kids who are cousins to each other getting to know each other and having a good time. Then the dread of the war starts to make waves — first far in the distance and then suddenly right at the backyard and the whole feel of the movie changes from joyful relationship drama to surviving in a war and kids taking care of other kids.

What I really like about Ronan's acting is that she's great at playing imperfect characters in broken worlds. This movie is one good example of that. The Outrun that I watched last time is another.

Tuesday: On Chesil Beach

On Chesil Beach (2017)

6.3/10

3.0/5

61%

Directed by Dominic Cooke

Starring Saoirse Ronan, Billy Howle, Anne-Marie Duff

In 1962 England, a young couple finds their idyllic romance colliding with issues of sexual freedom and societal pressure, leading to an awkward and fateful wedding night.

On Chesil Beach was on my original list last time but due to an admin error on my behalf (I accidentally used all my library streaming loans before watching it) had to skip it. Now it was time to right that wrong and borrow the movie from the library for this week's viewing.

I had high expectations for this movie based on the positive reviews I had read. Unfortunately it didn't quite do it for me.

Don't get me wrong, it's not by any means a bad movie. It's a good relationship drama set in 1960s where Florence (Saoirse Ronan) and Edward (Billy Howle) explore their relationship and figuring out how to have sex.

It just never clicked with me and I'm having difficulty pointing out exactly why. Having watched a bunch of Ronan's movies in a short time, I think she has many better performances playing somewhat similar characters.

Wednesday: Mary Queen of Scots

Mary Queen of Scots (2018)

6.3/10

3.1/5

65%

Directed by Josie Rourke

Starring Saoirse Ronan, Margot Robbie, Jack Lowden

In 1561, Mary Stuart, widow of the King of France, returns to Scotland, reclaims her rightful throne and menaces the future of Queen Elizabeth I as ruler of England, because she has a legitimate claim to the English throne.

Mary Queen of Scots is a magnificent movie of the 1500s monarchy power struggles in England and Scotland. It's one of the rare movies where the press tour — especially the visits of Saoirse Ronan and Margot Robbie at The Graham Norton Show — was the trigger for me to get interested in this movie.

I don't know or particularly care about how historically accurate it is. I know they made a bunch of artistic choices to make a more interesting story and I'm very fine with that. My knowledge or interest of 1500s history is not very high so I watched it like I would watch any medieval fantasy fiction.

And for that, it's a great movie. Ronan and Robbie, playing Mary and Elizabeth respectively, are both great at portraying strong women who need to keep all sorts of power hungry underlings in leash as they are many.

Thursday: See How They Run

See How They Run (2022)

6.5/10

3.2/5

63%

Directed by Tom George

Starring Saoirse Ronan, Sam Rockwell, Adrien Brody

In the West End of 1950s London, plans for a movie version of a smash-hit play come to an abrupt halt after a pivotal member of the crew is murdered.

See How They Run was a bit of surprising movie for me. I'm generally not a fan of traditional whodunnit movies but this one geared up better and better, especially through the relationship of Constable Stalker (Saoirse Ronan), an up and coming young police officer and her boss Inspector Stoppard (Sam Rockwell) who's not as enthusiastic and is reluctant to work with Stalker.

There's a fantastic short scene where Stalker is taking notes and Stoppard asks her how she knows if something is important. As a note geek, I loved it so much. (And yes, I may be stretching a bit on the concept of a "week" here but like Doctor Who said, "time is wibbly wobbly".)

The movie has two parallel stories: the aforementioned relationship and the actual murder mystery. During a stage play of a whodunnit mystery, a crew member is murdered and the police need to figure out who's behind the crime and why.

There's a lot of clever word play that I loved. The dialogue is sharp and witty and the characters have strong personalities, portraied in overly manner as is customary to stage play.

Friday: The Grand Budapest Hotel

The Grand Budapest Hotel (2014)

8.1/10

4.2/5

80%

Directed by Wes Anderson

Starring Ralph Fiennes, Tony Revolori (+ Saoirse Ronan)

The Grand Budapest Hotel tells of a legendary concierge at a famous European hotel between the wars and his friendship with a young employee who becomes his trusted protégé. The story involves the theft and recovery of a priceless Renaissance painting, the battle for an enormous family fortune and the slow and then sudden upheavals that transformed Europe during the first half of the 20th century.

After I shared the first blog post, I had a couple of discussions about her movies with friends and Wes Anderson's fantastic The Grand Budapest Hotel came up a few times.

It's not exactly a "Saoirse Ronan movie" as she plays a rather small supporting role but it's Friday and she's in the movie and I love that movie so I'm cashing in my Creative Freedom coupon and count this as one of her movies.

I've seen this movie so many times. When it came out, I was living in San Francisco and was friends with a guy who was a massive Anderson fan. I had never seen any of his movies or even heard of him before that but the recommendation from a friend led me to this movie. Oh boy I'm happy it did.

Every shot and scene in this movie is beautifully crafted. The sets are breath-takingly stunning, the action and dialogue is framed perfectly and while it has a certain wesandersonist absurdism to it, it flows so effortlessly and it's easy to enjoy.

Ronan's role as Agatha is not a big one but she does a great performance as the love interest of the young hotel lobby boy Zero. She's brave and cunning and pours her love and effort into pastry baking.

M is for meetups - Python A to Z

2026-08-14T00:00:00Z

You walk into a room that’s buzzing of nervous energy. Some people are chatting with each other, others are sitting alone in the corner looking at their phone or grabbing a drink or slice of pizza from the kitchen. After a moment, the MC welcomes everyone in and a speaker after another take the stage to talk about something they know.

You have likely been to a meetup. I love meetups. I’ve been participating in them for 13 years and have been running my own for over 10 years. A lot of my best friendships have started from those communities.

I have written about meetups and conferences from various perspectives in the past so consider this post as a literature review of sorts.

Developer's Guide to Communities is a good starting point. It’s my magnum opus on why and how to join meetup communities as a software developer. It covers everything from why you as a developer should join as a participant or even start sharing as a speaker all the way to what meetups are and how they function.

It's my first time at a meetup - how does it work? is a post I wrote for our local Python meetup group to give first-timers a feel for what they were joining if they decided to sign up for one of our events.

Shy introvert's (short) guide to speaking in conferences is for those who want to take the next step and start sharing their knowledge but are bit unsure. As I was traveling to Copenhagen to speak in Django Day 2022 conference, I wrote down all my best tips and tricks of how I — an introvert — navigate social conferences and get the best out of them.

In You can be a beginner and also a speaker, blogger, or participant Marijke Luttekes writes encouraging words to everyone who considers them self too inexperienced to share: “Have you recently heard yourself or someone else say that you cannot share knowledge because you are a beginner or junior developer? I hope to convince you otherwise.”

Chance of serendipity is my argument for giving events like meetups and conferences a chance. You never know what’s going to happen: who you’ll meet, what will inspire you — even to the extent of having life-changing experiences.

L is for learning - Python A to Z

2026-08-13T00:00:00Z

A life of a software developer — no matter if you’re doing it professionally or as a hobby — is a life of continuous learning. The technologies evolve, problem solving skills are never complete and thanks to very generous sharing from the community, there’s always new things to learn.

For today’s entry to Python A-Z, I’ll share different resources that I’ve found good for learning more about Python.

Books

Luciano Ramalho’s Fluent Python is still my number one recommendation. I wrote a recommendation for it two years ago so I won’t repeat too much here. It’s a really good book for anyone who knows Python and wants to deepen their knowledge and get a better grasp of writing Python code that takes the best advantage of all of the language’s structures.

Automate the boring stuff with Python by Al Sweigart is a good primer for Python (and available as free online book). It has a very positive, supportive and encouraging tone which is really nice because especially in the beginning, learning programming can be quite a challenging — but rewarding — endeavour.

Python Workout by Reuven M. Lerner is a good option if you have some experience writing Python under your belt but you want more exercise. It has 50 exercises to practice the basic fundamentals of Python. Each exercise is explained and teaches you different concepts in Python.

David Kopec’s Classic Computer Science Problems in Python is aimed for intermediate or advanced level developers and rather than teaching the basics, it focuses on interesting classic computer science problems (as one might guess from the name…) and how to solve those with Python. Each chapter focuses on a sub category of problems and at the end of the chapter ties it all together with how these skills are useful in real-world applications.

Podcasts

There are many interesting Python podcasts and for this, I also refer to my previous post in our Python meetup’s blog: Start your year with a new podcast.

Whether you want to learn about the nitty gritty details of building Python itself or want to hear stories of the people in the Python community, there’s something in the Python podcast world for everyone.

Blogs (and other forms of web writing)

Here are some of the blogs and people who do Python stuff from my RSS reader. I initially started writing about everyone and their blog (because info dumps are not a great reader experience) but there are so many great people on this list that it got overwhelming.

Going through the list, I’m so happy that I’ve gotten to know many people on this list in-person as well and compiling the list brought back a lot of great memories.

Adam Johnson
Andrea Grandi
Andrew Mshar
Anže Pečar
Carlton Gibson
Cheuk Ting Ho
Core Dispatch
Daniel Roy Greenfeld
Dawn Wages
Denny Perez
Georgi Ker
Gonçalo Valério
Hugo van Kemenade
James Bennett
Jeff Triplett
Johnny Metz
Luke Plant
Mariatta
Marijke Luttekes
Mario Munoz
Martin Heinz
Matthias Kestenholz
Maurits van Rees
Mia Bajić
Mostly Python
Nicolas Kuttler
Nik Kantar
Pamela Fox
Paolo Melchiorre
Peter Bengtsson
Savannah Ostrowski
Seth Larson
Sheena O'Connell
Simon Willison
Stefan Machura
Thomas Loiret
Tim Kamanin
Timo Zimmermann
Trey Hunner who also shares great daily tips in Mastodon

There’s also probably many that I have missed. My categorisation efforts in my RSS reader are not at the level I wish they were so there are probably many more that I read but couldn’t find or remember right now.

K is for keyword arguments - Python A to Z

2026-08-12T00:00:00Z

In PyCon US 2013, Raymond Hettinger talked about writing beautiful, idiomatic Python. It’s a great talk but for this post, I’ll focus on what he talks about around 30 minute mark.

He shares an example (which dates the talk and example nicely; those were the times)

twitter_search('@obama', False, 20, True)

We spend way more time reading code than we do writing it. While modern code editors and IDEs give you a lot of help (as you can see in the following screenshot from VS Code), it’s still an extra step.

Keyword arguments are a great, small step to improving the readability of your code. Compare the two:

twitter_search('@obama', False, 20, True)
# and 
twitter_search('@obama', retweets=False, numtweets=20, popularity=True)

The second one is immediately more readable and the better names for your keywords you write, the better its readability becomes.

J is for JSON validation - Python A to Z

2026-08-11T00:00:00Z

When you need to load external data into your software, you want to make sure it behaves properly, ie. it’s in correct form. One tool to validate input data is Pydantic. This is a quick tutorial to show how it works.

Installing Pydantic

Set up your environment and install with

pip install pydantic

Alternatively, you can run these with uv:

uv run --with pydantic code.py

Simplified Pokédex data

For this demo, I’m using a simplified data set adapted from Purukitto’s Pokemon.json. I’ve saved this to a file pokedex.json.

[
  {
    "id": 1,
    "name": "Bulbasaur",
    "type": ["Grass", "Poison"],
    "stats": {
      "HP": 45,
      "Attack": 49,
      "Defense": 49,
      "Sp. Attack": 65,
      "Sp. Defense": 65,
      "Speed": 45
    },
    "height": "0.7 m",
    "weight": "6.9 kg"
  },
  {
    "id": 2,
    "name": "Ivysaur",
    "type": ["Grass", "Poison"],
    "stats": {
      "HP": 60,
      "Attack": 62,
      "Defense": 63,
      "Sp. Attack": 80,
      "Sp. Defense": 80,
      "Speed": 60
    },
    "height": "1 m",
    "weight": "13 kg"
  }
]

Building a schema

Step 1: Basic types

Let’s start with a first step. We’ll define a class that inherits from Pydantic’s BaseModel. These classes will be the way we define the schema and what powers Pydantic’s validation engines.

For the first step, we’ll use basic definitions.

A Pokémon has a couple of fields: an id, a name, a list of types, a dictionary of stats, height and weight. A Pokedex is a list of Pokémon.

I will be using this as a base for all future snippets in this post but will only share what’s changed later on. You can find full code examples in GitHub.

import json

from pydantic import BaseModel
from typing import List, TypeAlias


class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: int
    name: str
    type: List[str]
    stats: dict
    height: str
    weight: str


Pokedex: TypeAlias = List[Pokemon]


def read_pokedex(filename: str) -> Pokedex:
    pokedex = []
    with open(filename, "r") as dex:
        data = json.load(dex)
        for entry in data:
            pokedex.append(Pokemon(**entry))
    return pokedex


if __name__ == "__main__":
    pokedex = read_pokedex("pokedex.json")
    print(pokedex)

Step 2: More refined types

Python itself offers enough for the basic types (like int, str , List and dict in the example above) but Pydantic offers a lot more if we want to be more specific.

For example, our id field is always a positive integer. We can use PositiveInt from Pydantic to add an extra layer of validation.

from pydantic import BaseModel, PositiveInt

class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: PositiveInt
    name: str
    type: List[str]
    stats: dict
    height: str
    weight: str

Everything else stays the same but we import PositiveInt and change id to it.

Now, lets we add a third element to our JSON to see how this works. Here, I’ve introduced a mistake in data: id is now -3 instead of 3.

{
    "id": -3,
    "name": "Venusaur",
    "type": ["Grass", "Poison"],
    "stats": {
      "HP": 80,
      "Attack": 82,
      "Defense": 83,
      "Sp. Attack": 100,
      "Sp. Defense": 100,
      "Speed": 80
    },
    "height": "2 m",
    "weight": "100 kg"
  }

If we run our code from step 1, all runs smoothly. If we run the code from step 2, we get a validation error:

pydantic_core._pydantic_core.ValidationError: 1 validation error for Pokemon
id
  Input should be greater than 0 [type=greater_than, input_value=-3, input_type=int]

Remember to switch -3 to 3 before continuing.

Step 3: Renaming fields

Our stats field looks like this:

    "stats": {
      "HP": 80,
      "Attack": 82,
      "Defense": 83,
      "Sp. Attack": 100,
      "Sp. Defense": 100,
      "Speed": 80
    }

We can use Pydantic’s alias feature to rename them to a more pythonic versions and add an extra layer of validation.

from pydantic import BaseModel, PositiveInt, Field
from typing import List, TypeAlias


class Stats(BaseModel):
    hp: PositiveInt = Field(alias="HP")
    attack: PositiveInt = Field(alias="Attack")
    sp_attack: PositiveInt = Field(alias="Sp. Attack")
    sp_defense: PositiveInt = Field(alias="Sp. Defense")
    speed: PositiveInt = Field(alias="Speed")


class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: PositiveInt
    name: str
    type: List[str]
    stats: Stats
    height: str
    weight: str

Here, we add an import for Field and create a new validation model Stats. For each field, we define the key in JSON as alias= argument and use the new Stats model in our Pokemon definition.

We now have added validation for all the stats and they are in a form that’s easier to use within Python code.

Step 4: Parse data into usable format

Our height and weight data is in a string format:

    "height": "2 m",
    "weight": "100 kg"

It would be easier to use them if they were stored numerically. Good news! We can run code before or after validation to modify the values.

Let’s start by writing functions to turn these data points into numbers:

def parse_height(height: str) -> float:
    height = height.removesuffix(" m")
    return float(height)


def parse_weight(weight: str) -> float:
    weight = weight.removesuffix(" kg")
    return float(weight)

We remove the unit suffixes and convert the rest to a float.

To run this, we need a few extra bits.

from pydantic import BaseModel, BeforeValidator, Field, PositiveFloat, PositiveInt
from typing import Annotated, List, TypeAlias

class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: PositiveInt
    name: str
    type: List[str]
    stats: Stats
    height: Annotated[PositiveFloat, BeforeValidator(parse_height)]
    weight: Annotated[PositiveFloat, BeforeValidator(parse_weight)]

We import three new things: pydantic.BeforeValidator , pydantic.PositiveFloat and typing.Annotated. (If we want to run code after value is validated, we could use pydantic.AfterValidator).

We then define height and weight as annotated floats and want to run their corresponding functions.

Now we can validate that the result of our parsing is a positive float for both of them and our code has access to properly typed values.

If our data used mixed units, this would also help us normalise the data. Here, all heights are in meters and weights are in kilograms so we didn’t have to do any conversions.

‘Tis but a scratch!

I’ve given you a glimpse into Pydantic’s validation tools and how to get started but there’s so much more you can do. They have pretty good documentation that will help you define and refine your validators even further.

Writing validators is not only good for catching up rogue, misformed data but it forces you to be explicit about understanding your data before you venture into building your program’s business logic.

I is for immutable - Python A to Z

2026-08-10T00:00:00Z

When we start learning programming, one of the first things we’re taught is a concept of variable. Variables are very handy: they store some data in memory, have a name you can use to refer to them later in the code and they can change.

That’s what variable means. Merriam-Webster defines the word as

able or apt to vary : subject to variation or changes

A classic example is a counter that goes up.

counter = 0
print(counter) # 0
counter = counter + 1
print(counter) # 1
counter = counter + 1
print(counter) # 2
counter = counter + 1
print(counter) # 3

Most of the early days, months or years of learning programming is about understanding this idea and a few related bits like different types (numbers, strings, lists, dictionaries, booleans etc), conditionals and loops. After you learn those, the rest of your career is just banging your head to the wall when the simple constructs you wrote don’t work (or you can talk to a duck and save a headache).

You build your internal schema of how to program based on the idea of a variable.

Functional programming

Then at some point — maybe at an advanced class at the university, at a meetup or in the always peaceful and polite discussion forums on the web — you’re introduced to the idea of immutability (not capable of or susceptible to change).

Someone comes hype the idea of functional programming that you’ve never heard of. They start talking about how changing variable state is so error-prone and pure functions is where the game should be played at.

A pure function is a function that given an input, always returns the same output. There are no side effects. It only relies on the inputs provided (and doesn’t read anything from disk, other parts of memory, make any web calls and so on) and is deterministic in crafting its output.

Pure functions are way easier to test, have less unexpected issues and can make your code easier to reason with. The hardcore functional programming people don’t even store values in temporary variables. They call functions, pass the results to other functions and beauty emerges and birds sing.

But if your entire schema of how programming works was laid on the foundations of variables, it can be quite a head scratcher to start adopting. I was on my third year at the university studying computer science when I took a functional programming course and oh boy it was a doozy.

I don’t know if that course was a blessing or a curse. There were maybe easier ways to get into understanding immutability and pure functions in programming but on the other hand, diving directly to the deep end and learning to swim might have been a good form of shock therapy.

I’m not a purist but I do prefer as much functional style as possible — mostly to help make code easier to test and thus reducing the stress of growing complexity.

Tuples are great, m’kay

Some data structures are immutable: once you make it, you gotta stick with it.

In Python, we have tuples (and their more eloquent heir namedtuples). You cannot change the contents of a tuple, no matter how hard you try.

date = (2026, 8, 10) # parentheses are optional but preferable

# Access them by index
print(date[0]) # 2026

# Can't change though
date[0] = 2025 
# TypeError: 'tuple' object does not support item assignment

I really like tuples. Especially namedtuples.

They also make me appreciate Python’s beautiful design. All you really need is a comma in between two expressions and you’ve got yourself an immutable tuple.

If you want to return multiple values from a function, it’s tuple time!

from typing import Tuple

def squares_and_cubes(number: int) -> Tuple[int, ...]:
  return number, number**2, number**3

Back in the day, I started with PHP and a bit later with Java at high school. When I moved into Python and learned about how easy it is to return multiple values through a tuple without having to explicitly craft a tuple, I started appreciating the language even more.

HTML Day and the value of practicing the fundamentals

2026-08-10T00:00:00Z

On August 8th, we celebrated this year’s HTML Day. (Or more accurately, many people around the world did. I tried to put together an event for our local community but failed to garner enough interest from speakers and partners and had to cancel. My failure left a disappointing taste to my mouth and I failed to celebrate the event on my own.)

Tom wrote a post Old Dog Not Understanding HTML Day where he expressed how he doesn’t get the appeal of HTML Day and writing HTML by hand.

As a professional software engineer and sometimes web developer, you’d think I’d be excited about something like HTML Day. But the fact is that I hate hand-writing HTML. I avoid it as much as possible.

Sorry.

Once again I’m in the uncomfortable position of looking at a fun thing people are having fun with and reacting with, “Huh? I don’t get it.”

To a certain extent, I agree with him: I dread the idea of writing a full website without any HTML generating tooling — outside an event like this. I love my Emmet snippets and static site generators so I can define the basic structures and let the machine go brrrrr and build the rest.

I especially agree with Tom’s later remark about using Markdown when writing instead of mixing creative writing and HTML implementation:

I find it vastly easier and more intuitive to creatively write in Markdown than in HTML, when it comes to simple formatting like italics and bold and headings and such.

The bits that I do write, I want to write myself by hand because it gives me greater control to make sure the output is as good, semantic HTML as possible.

Practicing the fundamentals

First, let’s talk about HTML Day (and by extension, Advent of Code he also mentioned).

I think there’s tremendous value in gathering together as a community of practice to learn more about a topic, sharing good ideas and practicing your craft.

Even if we strip out the community benefits and even if you’d mostly generate your HTML by some sort of a tool on your day-to-day basis, I think it’s really good to regularly get back to the basics and practice them. If you’re not a developer who does web frontend, it’s not as important but for anyone who does.

HTML changes over time and it’s good to check what’s up with the standards, new options and best practices. When I started getting into frontend stuff back in my teens, we used iframes and tables to create layouts — now we have flexbox and CSS grid as an example. Smaller things happen all the time as well and taking a moment every now and then to check where you are is good.

Second, even if you generate your code, you need to know and have a feel for the fundamentals so you can judge if the code that was generated is any good.

Tom writes:

There’s that pesky elephant in the room in 2026 again. AI. It’s hard to escape the universal answer to most development questions: I can just get AI to write or check whatever HTML I need so I don’t have to get distracted by troublesome details while I stay focused on the big picture. Laziness, hurray!

The more you use AI to generate your code — in any language — the more you should focus on making sure your fundamentals of the language are good so you can assess the code it gives you.

Our industry is famously quite bad at writing good HTML. Especially with the popularity of React, there are a lot of frontend developers who don’t know the fundamentals and through that lack of knowledge, end up writing inaccessible solutions or having to reinvent the wheel while they could rely on built-in tools in HTML and browsers to make websites and web apps accessible.

I don’t want to write all the HTML in my projects by hand every time. However, I do find a lot of value in regularly doing so to keep up with new advancements in the language as well as honing my fundamental skills.

I also love this quote from Brian Holt:

When I don’t know how my tools work, I tend to resent them because they add complexity to my life.
When I understand what they are doing for me and what I no longer have to do because the tool is doing it for me, I tend to really like my tools.

Sometimes doing things the hard way makes me appreciate the tooling I have so I don’t have to do it every time.

H is for htmx - Python A to Z

2026-08-09T00:00:00Z

For the past couple of years, all my new Django projects have been built with htmx and I’ve worked on couple of other, non-Django projects that uses it as well. It’s a blast!

It took me a while to get used to but especially this demo by Michael Kennedy at PyBay 2021 convinced me of its utility and looking back now, I love how simple it makes building most interactive websites and web apps.

htmx is a small (16k) Javascript library that makes it possible to build modern UIs by transferring HTML over the wire instead of JSON. Combined with Django’s templating system, it makes build smooth, fluid frontends with server-side rendering.

Here’s an example from my Pokémon TCG inventory application. I have a component for showing a card and a (-) [count] (+) style UI for it.

<button
	name="decrease-qty"
	id="{{card.id}}-{{variant.variant|slugify}}"
	data-foil="{{variant.variant}}"
	hx-put="/collection/decrease/{{variant.id}}/"
	hx-target="input#{{card.id}}-{{variant.variant|slugify}}"
	hx-swap="outerHTML"
>
-
</button>

Here’s a button that decreases the amount in my database. It uses three htmx attributes: hx-put, hx-target and hx-swap.

hx-put tells the code to send a PUT request to the provided endpoint when this button is clicked.

hx-target tells which element the returned HTML in the response should go into.

hx-swap tells how to change it: in this case, replace the entire HTML element of the target.

I click the button in the UI, a PUT is sent to the server that updates the count in the database and sends back HTML that in this case is an input with the value of the new count (and some extra htmx controls so I can change the value directly in the input as well).

HTMX 4.0, the first JavaScript library to release exclusively on the Game Boy® platform!

There’s also a Game Boy game by htmx and Seth Larson made a video and wrote a blog post about it.

G is for get_or_create - Python A to Z

2026-08-08T00:00:00Z

Let’s take our first journey into the wonders of Django, my favourite web backend. One of the reasons I love it is its ORM which we’ll talk a bit more when we reach the midway of the month and letter O.

Today, I want to show my appreciation for one of the methods in QuerySet: get_or_create which allows you to create new items in the database but if one already exists, it returns it instead.

from .models import Bread, BreadType

# (here, Bread.bread_type is a ForeignKey to BreadType)

breads_input = [{ 'id': 1, 'breadType': 'bun' } , ... ]

for bread_data in breads:
	bread_type, type_created = BreadType.objects.get_or_create(type=bread_data['breadType'])
	bread, bread_created = Bread.objects.get_or_create(id=bread_data['id'], bread_type=bread_type)

Here we process through some list of dictionaries (imagine it’s read from a JSON file or queried from a REST API). First, we try to create a new BreadType but if one already exists, we return a reference to it rather than creating a new one every time. Then we create a bread, using the previous reference. If we’d already have that specific bread inputted (maybe we ran the command twice), we want to get the existing one rather than creating new ones every time.

I especially love using it in my data entry scripts / custom Django commands. Many of my applications operate on a model where I periodically input new data through these commands: for example in Pokémon TCG app, when a new set is released.

Pokémon TCG is a great example. Right now, when my script reads in data for new cards, there are 13 such relationships between my Card model and other models. The codebase looks so much neater and easier to follow thanks to get_or_create.

Edit later on Aug 8th: I rewrote the entire post to better explain what get_or_create does.

My custom keyword reference guide for Magic the Gathering Battle Box

2026-08-07T00:00:00Z

I’ll start by playing a Forest.

Sure, it resolves.

I’ll tap the Forest to generate green mana and use it to cast Battle Box keyword reference guide.

I love Magic the Gathering Battle Box. It’s a great casual pick-and-play format where I can bring it with me to a lunch or an afterwork, shuffle the deck and start playing.

No need for everyone to bring their own deck, no long-winded drafting (although drafting cubes is hella fun) and deck construction. No mana drought or mana flood but a perfect curve.

A single, shared deck full of creatures and other spells that mostly focuses on combat and combat tricks. Each player has 10 lands (1 of each basic and 5 dual-lands) they can play from Command Zone (I’m considering calling it Landfill for the memes).

There’s just one catch.

“Reading the card explains the card” doesn’t always work. With casual players and a bunch of unexplained keywords (like Menace, Madness, Shadow, Surveil), it can be bit of a burden to figure out what the cards do.

That’s why I compiled my own Battle Box keyword reference guide (see the thing I did in my intro where I used a Forest to cast a booklet. smart, huh?): it lists all 41 keywords that are present in my deck in alphabetical order and explains how they work. And the back cover has a quick guide for what “instant speed” and “sorcery speed” mean and when you can activate abilities and mana abilities.

Now, instead of players having to expose what they have in hand and ask me or awkwardly search the wiki on their phone, they can pick up the guide and check.

It was such a fun project and it looks gorgeous.

F is for f-strings - Python A to Z

2026-08-07T00:00:00Z

Programming languages have many ways to combine literal strings and variables. For a decade now, we in Python land have been able to enjoy the beauty and elegance of f-strings.

f-string is a string that is prefixed with the letter f:

string_type = 'f-string'
print(f'This is a {string_type}')

When you craft an f-string, you can evaluate Python code inside it by placing it inside curly braces `{ … }`.

In addition to simply putting in a variable, there are a bunch of format specifications that allow further modification of the output. fstring.help has a really handy reference sheet for these but here are some that I use regularly.

Padding numbers

File browsers usually default to sorting alphabetically so if you have files 1.json, 2.json and 10.json, the 10 will sort before the 2. So to keep things neat and tidy, I often left-pad with zeroes to force proper sorting:

for filename in range(1, 20):
  print(f'{filename:02d}')
  
# Prints 01, 02, 03, ... 20

Here 0 is the value we use to fill and 2 is the width to how many characters we want to pad up to.

Aligning text

When I build command line tools, I want a well-defined output structure and aligning items left or right with a given width is helpful.

name, goals = 'Juhis', 20
print(f'{name:<10}{goals:>5}')
# 'Juhis        20'

< is for left-align, > is for right-align, ^ would be for center and the number is the width. In this example, it guarantees that the name field is at least 10 characters and goals field is 5.

You can combine this with the previous example if you want to fill the empty space with something else, like underscore:

item, value = 'Cucumber', 14
print(f'{item:_<10}{value:_>5}')
# Cucumber_____14

Debugging

For debugging, I use two formats. (Btw, if you wanna get better at debugging, check out Debugging Python and if you’re curious about why printing is a good debug tool, read print is your best debugging tool.)

The first one uses = sign to print out the name of the variable and its value separated with an equal sign. It’s a short hand for f'value={value}' .

unknown = 400
print(f'{unknown=}, {unknown = }') # Whitespace is preserved
# unknown=400, unknown = 400

The second one uses !r to print out object’s __repr__ value.

class Card:
	def __init__(self, name, number):
	  self.name = name
	  self.number = number
	  
	def __repr__(self):
	  return f'Card("{self.name}", {self.number})'

card = Card('Pikachu', 25)
print(f'{card!r}')
# Card("Pikachu", 25)

Percentages

The last one is actually something I didn’t know about before I started writing this but can be handy. You can convert floats to percentages with :.0%:

percent = 0.3738
print(f'{percent:.0%}')
# 37%

print(f'{percent:.2%}')
# 37.38%

It’s pretty handy!

E is for environment variables - Python A to Z

2026-08-06T00:00:00Z

The code that a program runs is provided by the developer of the program. The inputs and interactions are initiated by the user of the program. The environment variables are data provided by the system that runs it. They are used to abstract configuration to the system level so that the same code can be ran in different environments and act differently (for example, development vs production environments).

Accessing environment variables

In Python, you can access environment variables through os.environ dictionary.

If you run the following in a REPL, you’ll see all the environment variables Python has access to.

>>> for variable, value in os.environ.items():
...     print(f'{variable}: {value}')
...

The os.environ is created at the time Python started and won’t update to reflect changes in environment variables that happen while the program is running. You can use os.reload_environ to update the values.

Automatically read variables from .env

It’s common to store project-specific configuration values in a .env file instead of managing the operating system level variables and having to remember to do that on every machine when they change.

To automatically read the values from .env, you can use python-dotenv.

# Example from dotenv documentation
# https://pypi.org/project/python-dotenv/

from dotenv import load_dotenv

load_dotenv()

Environment variables are often used to store secrets and accidentally leaking such secrets can be catastrophic. There’s a command line tool dotenvx that enables you to encrypt your secrets and then inject them to Python programs at runtime.

D is for dictionaries - Python A to Z

2026-08-05T00:00:00Z

Dictionary is a data structure in Python that in other contexts and languages is called an associative array, akey-value store or a map. It’s a handy and efficient data structure for when you need to store and retrieve a value based on a key.

This is a 101 level introduction to dictionaries.

Dictionary

Creating a dictionary

The basic form of dictionary can be created in couple of ways:

# dict constructor with keyword arguments
scores = dict(Charlie=10, Patty=25, Snoopy=30)

# dict constructor with tuples
scores = dict(('Charlie', 10), ('Patty', 25), ('Snoopy', 30))

# key: value pairs
scores = { 'Charlie': 10, 'Patty': 25, 'Snoopy': 30 }

# dict comprehension
data = [('Charlie', 10), ('Patty', 25), ('Snoopy', 30)]
scores = { key: value for key, value in data }

In each of these cases, the names are keys and numbers are values.

There’s one big restriction to the keys of dictionaries: they need to be hashable:

An object is hashable if it has a hash value which never changes during its lifetime (it needs a __hash__() method), and can be compared to other objects (it needs an __eq__() method). Hashable objects which compare equal must have the same hash value.

So you can’t use a list as a key for example because it’s a mutable one.

Accessing values

Regardless of what was used to create it, we can access the values in a couple of ways:

scores = { 'Charlie': 10, 'Patty': 25, 'Snoopy': 30 }

# With brackets
scores['Charlie'] # == 10

# With .get()
scores.get('Charlie') # == 10

The difference between these two is what happens when a key does not exist.

scores['Linus']  # raises KeyError: 'Linus'
scores.get('Linus')  # is None

# We can give .get() a default value
scores.get('Linus', 0)  # == 0

Changing values

Dictionaries are mutable data structures which means you can change their data.

# Set new value
scores['Charlie'] = 15

# Modify a value
scores['Charlie'] += 5

# Delete a key
del scores['Charlie']

Since there is a direct “one key to one value” relationship, dictionaries are very handy in collecting data for or counting values belonging to this key.

Let’s say we have a dataset where each time someone scores a point, their name is listed. We then want to count how may points each has:

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

scores = {} # Creating an empty dict
for person in marks: # Go through every mark
  if person not in scores: # If it's not in the dict yet,
    scores[person] = 0 # create an entry with starting value 0
  
  scores[person] += 1 # Add 1 point to this person
  
print(scores)
# {'Charlie': 3, 'Patty': 1, 'Snoopy': 4}

We’ll look a bit later how we can improve this with some of the special dictionaries but this basic structure of turning data into a dictionary is a fundamental basic to learn in Python.

While the key needs to be hashable, the values can be anything. So instead of just increasing a number from zero upwards, we could store data as a list or another dictionary or whatever.

Looping over

# By default, loops over keys in for-in
for person in scores:
  print(person, scores[person])
  
# Loop over values
for score in scores.values():
  print(score)
  
# Loop over both
for person, score in scores.items():
  print(person, score)

Sorting a dictionary

On a concept level, basic mapping does not have an order. In Python, dictionaries maintain the order the keys are inserted in and there are ways to force an order (like OrderedDict) but it’s a good baseline to base your knowledge of dictionaries on.

However, when looping over a dictionary, you often want the data to be in some sort of order. In the earlier example when we counted marks to a dictionary, we might want to print it in an order of most points to least.

For this, we can use sorted function:

# Let's recreate our dictionary
scores = {'Charlie': 3, 'Patty': 1, 'Snoopy': 4}

for person in sorted(scores, key=scores.get, reverse=True):
  print(f'{person}: {scores[person]}')
  
# Snoopy: 4
# Charlie: 3
# Patty: 1

The first argument to sorted is in this case our dictionary. The second key, key= is a single argument function that defines what is used for sorting (in this case, scores.get tells the function we want the values corresponding to the keys) and reverse= can be used to reverse the order from ascending to descending.

It’s important to note that nothing internally in the dictionary changes when using sorted. It returns a new list with the keys sorted based on the sorting criteria.

You’ll do just fine with dictionary for a long time

Next, I’ll introduce some specialised dictionaries that are included in the standard library because developers have found these cases very useful. If you’re a new developer, I do recommend focusing on using and understanding the basic dictionary.

There’s nothing in the following dictionaries that you can’t do in the basic one.

Brian Holt once said this in one of his containers course:

When I don’t know how my tools work, I tend to resent them because they add complexity to my life.
When I understand what they are doing for me and what I no longer have to do because the tool is doing it for me, I tend to really like my tools.

Jumping into the more advanced use cases before understanding the basics really well can be detrimental. Finish this blog post to see what’s out there but don’t be afraid to manually write the code they would let you skip over and over again so that you’ll gain a deeper understanding.

defaultdict

In the earlier example of creating and populating a dictionary, we had to check if a key existed before we could interact with it:

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

scores = {} # Creating an empty dict
for person in marks: # Go through every mark
  if person not in scores: # If it's not in the dict yet,
    scores[person] = 0 # create an entry with starting value 0
  
  scores[person] += 1 # Add 1 point to this person
  
print(scores)
# {'Charlie': 3, 'Patty': 1, 'Snoopy': 4}

There’s a way to shortcut this by using a defaultdict:

from collections import defaultdict

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

# Create a new dictionary with
# default value of 0 for each key
scores = defaultdict(int) 

for person in marks:
  scores[person] += 1
  
print(scores)
# defaultdict(<class 'int'>, {'Charlie': 3, 'Patty': 1, 'Snoopy': 4})

Passing int to defaultdict tells the dictionary to start from a default value of 0. You could also pass list and the default would be an empty list. As you can see comparing the two examples above, the code becomes way easier to read and comprehend.

Counter

Our example of counting things is such a common operation that there’s a special Counter dictionary for it.

from collections import Counter

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

scores = Counter(marks)

print(scores)
# Counter({'Snoopy': 4, 'Charlie': 3, 'Patty': 1})

Not only does Counter help us in creation of it but it has a couple of really handy methods.

I have written about Counter before and rather than repeating myself here, I recommend reading through that post.

C is for command line interfaces - Python A to Z

2026-08-04T00:00:00Z

Python is a great language for writing scripts that are executed from the command line. I’m a big fan of command line interfaces and love building them for all sorts of needs both personally and when I’m part of a team.

Command Line Interface Guidelines

An integral part of command line software is dealing with arguments and options. In this post, I’ll focus on the technical part within the Python code but I highly recommend reading Command Line Interface Guidelines. It’s an open source guide to “help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day”. I keep it at hand and always refer to it when I’m designing my interfaces.

Simple arguments through `sys.argv`

For the simplest use cases, accessing the list of arguments through sys.argv is the best option. I usually use it at the beginning while I’m still forming the ideas of what the tool will look like or when the script only requires one or two positional arguments.

Let’s say we run a script with the following:

python script.py 2 file.txt

To access those arguments, we write script.py to be:

import sys

script_name = sys.argv[0]  # script.py
copies = sys.argv[1]  # 2
filename = sys.argv[2]  # file.py

You can’t trust the user to always provide the right amount of arguments though so it’s a good idea to add some checks and instruct the user how to use it properly.

import sys

if __name__ == "__main__":
    arguments = sys.argv
    if len(arguments) < 3:
        print("""Two arguments required for the amount of copies and the filename.
    
Usage; script.py <amount of copies> <filename>""")
        sys.exit(1)

    copies = arguments[1]
    filename = arguments[2]

This provides a top level check AND documentation at the same time and is a great habit to get into.

Documentation-first approach with docopt

Speaking of documentation, docopt and its maintained Python implementation docopt-ng provide a documentation-driven way for declaring the command line interface.

Defining the interface first leads to better user experience. In my experience, starting with implementation details often leads to either suboptimal interfaces or spaghetti code to try to mend an implementation to interface later. If you start by thinking how the user should interact with the application, then the rest follows to fill the gaps in an elegant way.

Using docopt, you write the usage pattern in your docstring and let the tool figure out what arguments and options it needs to derive from it (example from docs):

"""Naval Fate.

Usage:
  naval_fate.py ship new <name>...
  naval_fate.py ship <name> move <x> <y> [--speed=<kn>]
  naval_fate.py ship shoot <x> <y>
  naval_fate.py mine (set|remove) <x> <y> [--moored | --drifting]
  naval_fate.py (-h | --help)
  naval_fate.py --version

Options:
  -h --help     Show this screen.
  --version     Show version.
  --speed=<kn>  Speed in knots [default: 10].
  --moored      Moored (anchored) mine.
  --drifting    Drifting mine.

"""
from docopt import docopt


if __name__ == '__main__':
    arguments = docopt(__doc__, version='Naval Fate 2.0')
    print(arguments)

I have written about docopt a few years ago and that post still holds water so I recommend you go read that for more information.

Click

The library I use most often these days — because it works so nicely with custom Django commands with django-click — is click. Click uses Python decorators to define commands, subcommands, arguments and options.

# Example from click documentation
# https://click.palletsprojects.com/en/stable/

import click

@click.command()
@click.option('--count', default=1, help='Number of greetings.')
@click.option('--name', prompt='Your name',
              help='The person to greet.')
def hello(count, name):
    """Simple program that greets NAME for a total of COUNT times."""
    for x in range(count):
        click.echo(f"Hello {name}!")

if __name__ == '__main__':
    hello()

You can add extra validation through callbacks directly at this level which makes the actual code of your application a bit cleaner when the validation and first level input processing is done before the arguments and options ever reach your application logic.

# Example from click documentation
# https://click.palletsprojects.com/en/stable/advanced/#callbacks-for-validation

def validate_rolls(ctx, param, value):
    if isinstance(value, tuple):
        return value

    try:
        rolls, _, dice = value.partition("d")
        return int(dice), int(rolls)
    except ValueError:
        raise click.BadParameter("format must be 'NdM'")

@click.command()
@click.option(
    "--rolls", type=click.UNPROCESSED, callback=validate_rolls,
    default="1d6", prompt=True,
)
def roll(rolls):
    sides, times = rolls
    click.echo(f"Rolling a {sides}-sided dice {times} time(s)")

With django-click, you can use the same interface to define an interface for your custom commands.

import djclick as click

@click.command()
@click.option("--file", help="Load set from a local JSON file")
def command(file):
	...

B is for batteries included - Python A to Z

2026-08-03T00:00:00Z

Python is often described as having batteries included

The Python source distribution has long maintained the philosophy of “batteries included” – having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects. - from withdrawn PEP 206

I love Python’s batteries included philosophy and its standard library so much that I dedicated an entire Blaugust in 2024 writing about it:

At PyCon Finland 2025, we got this cool LEGO Python logo that had batteries included: