After a 7 year hiatus, I’m attempting to start this annual habit again, starting with audiobooks I read in 2024. But first, I’ll reflect on some of the books that have stuck with me from 2017 through 2023.

Books that have stuck with me from 2017 to 2023

Of the 206 books I read over the 7 years of 2017 through 2023, about 35 books really stuck with me and I would recommend reading all of them.

Each section in ordered roughly by how much I would generally recommend the book (the first book in each section I usually recommend more than the last). I enjoyed all these books, but I didn’t write a review for all of them. I’ve included links when I did write a review.

Really enjoyable Sci-Fi (and a bit of Fantasy) that’s stuck with me:

• Dawn (and also Adulthood Rites) by Octavia Butler
• The Long Way to a Small, Angry Planet (& A Closed and Common Orbit) by Becky Chambers
• The Fifth Season (and the other 2 books in the series) by N.K. Jemisin
• Hive Minds Give Good Hugs by Natalie Maher
• Parable of the Sower (and Parable of the Talents) by Octavia Butler
• A Song for a New Day by Sarah Pinsker
• The City We Became by N.K. Jemisin

Books on human progress (to extinguish your cynicism):

• Enlightenment Now by Steven Pinker
• Factfulness by Hans Rosling
• The Fabric of Civilization: How Textiles Made the World by Virginia Postrel

The book that has most shaped my charitable giving habits:

• The Life You Can Save by Peter Singer (free here)

My favorite self-improvement books:

• Mind Management, Not Time Management by David Kadavy
• The Scout Mindset by Julia Galef
• Deep Work by Cal Newport
• The Joy of Movement by Kelly McGonigal
• Learn Like a Pro by Barbara Oakley, Olav Schewe
• Atomic Habits by James Clear
• Good Habits, Bad Habits by Wendy Wood

Books on economics, government, and public policy that aren’t about housing and city planning:

• Basic Economics: A Citizen’s Guide to the Economy by Thomas Sowell
• Recoding America by Jennifer Pahlka
• Drug Use for Grown-Ups: Chasing Liberty in the Land of Fear by Carl L. Hart
• How Rights Went Wrong by Jamal Greene

Books on housing and city planning that have shaped my YIMBY-ish views:

• Happy City by Charles Montgomery
• Arbitrary Lines: How Zoning Broke the American City and How to by M. Nolan Gray
• Walkable City: How Downtown Can Save America, One Step at a Time by Jeff Speck
• Paved Paradise: How Parking Explains the World by Henry Grabar

Books on xenophobia and other-ing that have particularly stuck with me:

• Caste by Isabel Wilkerson
• The Sum of Us: What Racism Costs Everyone and How We Can Prosper Together by Heather McGhee

Books that have impacted my very gradual journey toward veganism:

• Why We Love Dogs, Eat Pigs, and Wear Cows by Melanie Joy
• The End of Animal Farming by Jacy Reese Anthis

TV shows I’ve (so far) liked more than the books they’re based on:

• Silo (Apple TV)
• The Power (Amazon Prime)
• The Three-Body Problem (Netflix, though Amazon Prime has a much slower Chinese version)

Note that the above books do not include books I listened to in 2014, 2015, and 2016. See my other audiobook posts here. Of those 3 years of books, the ones that I’d recommend most are Success and Luck by Robert H. Frank (2016), Just Mercy by Bryan Stevenson (2014), Whistling Vivaldi by Claude M. Steele (2015), and Make it Stick by Peter C. Brown, Henry L. Roediger III, Mark A. McDaniel (2016).

Also note that all the links above point to Goodreads, which I don’t recommend despite the fact that I use it. I plan to eventually switch to The Story Graph for recording my reading activity, but I’m awaiting an API so I can update my current reading-tracking system (which is based around a Google Sheet totaling hours read and other stats) to use it instead of Goodreads.

My favorite audiobooks of 2024

I read 41 audiobooks this year.

These are the ones I would most recommend listening to.

• Best self-help book:
  • Eat, Drink, and Be Healthy: The Harvard Medical School Guide to Healthy Eating
• Best page-turners:
  • Says Who? A Kinder, Funner Usage Guide for Everyone Who Cares About Words
  • A Little Devil in America: Notes in Praise of Black Performance
• Most thought-provoking:
  • Land is a Big Deal: Why rent is too high, wages too low, and what we can do about it
  • The Myth of Left and Right: How the Political Spectrum Misleads and Harms America
  • Uncommon Sense Teaching: Practical Insights in Brain Science to Help Students Learn
• Validated my current world view and I recommend read to challenge themselves:
  • Not the End of the World: How We Can Be the First Generation to Build a Sustainable Planet
  • Determined: A Science of Life without Free Will
  • Eating Animals

Eat, Drink, and Be Healthy: The Harvard Medical School Guide to Healthy Eating

This is the best book I’ve read about nutrition. This book contains no silver bullets; just evidence-backed advice.

If you’re reading this in audiobook-form, note that the last portion of the book contains recipes, read out-loud for many minutes… so I would stop listening once the recipes start. I’m considering buying a hard copy for some of the recipes.

Says Who? A Kinder, Funner Usage Guide for Everyone Who Cares About Words

This book pleased my inner wordy and challenged my inner grammando (those terms are explained in the book).

If you enjoy poking at the English language, I think you’ll find this a fun listen.

A Little Devil in America: Notes in Praise of Black Performance

This is a beautifully written book.

If you enjoy writing that’s thought-provoking, emotional, and engrossing, read/listen to this.

Land is a Big Deal: Why rent is too high, wages too low, and what we can do about it

This book is all about implementing a “land value tax” and it does a good job of explaining what that means and what the consequences might be. A land value tax feels like an extreme marriage of capitalism and socialism, as it would (sort of) abolish private ownership of land while encouraging the market to make the best use of each piece of land. The subject of this book is very wonky so this book was a bit challenging at times, but I found it fairly accessible overall.

For the sake of affordable housing, loosening or removing zoning restrictions (see the book Arbitrary Lines mentioned above) and reducing regulatory requirements around construction seem more important than a land value tax. But as far as taxes go, a land value tax does seem like the most justice-oriented and efficiency-oriented tax.

The Myth of Left and Right: How the Political Spectrum Misleads and Harms America

I prefer a good short book to a good long book and this audiobook very much justifies the time it took to read (4 hours).

If you frequently talk about or think about US politics, I would recommend reading this book. The authors make a solid case that we do a disservice to political discourse when we use the words “left”, “right”, “liberal”, and “conservative”.

Uncommon Sense Teaching: Practical Insights in Brain Science to Help Students Learn

Much of this book was review for me: namely interleaved versus blocked practice, active versus passive learning, elaboration, and spaced repetition. Even the parts that were review were helpful to hear again. I also took notes from this book about “learn it, link it”, dopamine hits, comprehension checks, and pauses to consolidate.

This book included quite a bit more discussion about how the brain actually works than I remember hearing in previous books I’ve read on learning and teaching. It could be that these sections were simply more memorable than previous explanations I’ve heard, as the explanations in this book heavily relied on memorable analogies and stories.

Not the End of the World: How We Can Be the First Generation to Build a Sustainable Planet

This book discusses what we focus on too much and too little when it comes to the problems and the solutions around climate change. Hannah Ritchie calls out falsehoods and misconceptions, but she doesn’t berate believers of these misconceptions.

We all care about solving global warming and sustainability. Knowing more of the facts behind these concepts is the first step to working solutions.

This book definitely falls into the “skepticism over cynicism” category that I very much appreciate, as it inspires action instead of of encouraging inaction.

If you enjoy a Scottish accent, listen to the audiobook (Hannah Ritchie self-narrates).

Determined: A Science of Life without Free Will

Before reading this book, I hadn’t considered that free will comes in shades and that as a society we have been gradually chipping away at the magnitude of free will we collectively believe in.

The first 9 chapters (especially 5 through 9) are a bit of a slog, as each focuses on disputing a different argument for free will. I found the final 5 chapters (which focus on “what do we do if there’s no free will”) the most interesting.

Eating Animals

This book was memorable in a somewhat brutal way. I do not recommend reading this book while eating animal products, but I would recommend reading it.

There’s quite a bit of navel-gazing, but also quite a few interviews with many a number of folks in and around the animal farming industry.

For a more hopeful take on animal welfare, see the book The End of Animal Farming (mentioned above). Also see the book Why We Love Dogs, Eat Pigs, and Wear Cows (also mentioned above)

Where to buy audiobooks (not Audible)

Interested in listening to these in audiobook form?

Don’t buy them from Audible.

Whenever possible, I recommend avoiding Audible because:

1. Audible doesn’t sell audiobooks; they sell the ability to play audiobooks through their app
2. Audible credits expire and also disappear upon cancellation, which is an awful dark pattern

Cory Doctorow has written about his dislike of Audible and has recorded an audiobook against Audible (which is ironically also on Audible).

If you enjoy audiobooks and pro-consumer practices, I recommend trying out Libro.fm (that’s a referral link which will give me one free audiobook if you subscribe).

Unfortunately, a few of my favorite audiobooks noted above are only available on Audible.

You can purchase all of the above books on Libro.fm except for Hive Minds Give Good Hugs, Recoding America, and Walkable City. The book Land is a Big Deal is technically available outside of Audible, but I’ve only found it available for direct purchase from the publisher and it’s much more expensive that way.

For most of my audiobook-listening, I subscribe to Libro.fm, checkout books from my local library with Libby, and I’ve also used Spotify to listen to a few shorter books. For Audible-only books, I sign up for a subscription, buy licenses until my credit balance is 0, and then cancel.

Have a recommendation?

Have a question? Have an audiobook recommendation for me?

Comment below.

It’s so easy to throw together a single-file Python command-line script and throw it in my ~/bin directory!

Well… it’s easy, unless the script requires anything outside of the Python standard library.

Recently I’ve started using uv and my primary for use for it has been fixing Python’s “just manage the dependencies automatically” problem.

I’ll share how I’ve been using uv… first first let’s look at the problem.

A script without dependencies

If I have a Python script that I want to be easily usable from anywhere on my system, I typically follow these steps:

1. Add an appropriate shebang line above the first line in the file (e.g. #!/usr/bin/env python3)
2. Set an executable bit on the file (chmod a+x my_script.py)
3. Place the script in a directory that’s in my shell’s PATH variable (e.g. cp my_script.py ~/bin/my_script)

For example, here’s a script I use to print out 80 zeroes (or a specific number of zeroes) to check whether my terminal’s font size is large enough when I’m teaching:

1
2
3
4
5
6

#!/usr/bin/env python3
import sys

numbers = sys.argv[1:] or [80]
for n in numbers:
    print("0" * int(n))

This file lives at /home/trey/bin/0 so I can run the command 0 from my system prompt to see 80 0 characters printed in my terminal.

This works great! But this script doesn’t have any dependencies.

The problem: a script with dependencies

Here’s a Python script that normalizes the audio of a given video file and writes a new audio-normalized version of the video to a new file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

"""Normalize audio in input video file."""
from argparse import ArgumentParser
from pathlib import Path

from ffmpeg_normalize import FFmpegNormalize


def normalize_audio_for(video_path, audio_normalized_path):
    """Return audio-normalized video file saved in the given directory."""
    ffmpeg_normalize = FFmpegNormalize(audio_codec="aac", audio_bitrate="192k", target_level=-17)
    ffmpeg_normalize.add_media_file(str(video_path), audio_normalized_path)
    ffmpeg_normalize.run_normalization()


def main():
    parser = ArgumentParser()
    parser.add_argument("video_file", type=Path)
    parser.add_argument("output_file", type=Path)
    args = parser.parse_args()
    normalize_audio_for(args.video_file, args.output_file)


if __name__ == "__main__":
    main()

This script depends on the ffmpeg-normalize Python package and the ffmpeg utility. I already have ffmpeg installed, but I prefer not to globally install Python packages. I install all Python packages within virtual environments and I install global Python scripts using pipx.

At this point I could choose to either:

1. Create a virtual environment, install ffmpeg-normalize in it, and put a shebang line referencing that virtual environment’s Python binary at the top of my script file
2. Turn my script into a pip-installable Python package with a pyproject.toml that lists ffmpeg-normalize as a dependency and use pipx to install it

That first solution requires me to keep track of virtual environments that exist for specific scripts to work. That sounds painful.

The second solution involves making a Python package and then upgrading that Python package whenever I need to make a change to this script. That’s definitely going to be painful.

The solution: let uv handle it

A few months ago, my friend Jeff Triplett showed me that uv can work within a shebang line and can read a special comment at the top of a Python file that tells uv which Python version to run a script with and which dependencies it needs.

Here’s a shebang line that would work for the above script:

1
2
3
4
5
6
7

#!/usr/bin/env -S uv run --script
# /// script
# requires-python = ">=3.12"
# dependencies = [
#     "ffmpeg-normalize",
# ]
# ///

That tells uv that this script should be run on Python 3.12 and that it depends on the ffmpeg-normalize package.

Neat… but what does that do?

Well, the first time this script is run, uv will create a virtual environment for it, install ffmpeg-normalize into that venv, and then run the script:

1
2
3
4
5

$ normalize
Reading inline script metadata from `/home/trey/bin/normalize`
Installed 4 packages in 5ms
usage: normalize [-h] video_file output_file
normalize: error: the following arguments are required: video_file, output_file

Every time the script is run after that, uv finds and reuses the same virtual environment:

1
2
3
4

$ normalize
Reading inline script metadata from `/home/trey/bin/normalize`
usage: normalize [-h] video_file output_file
normalize: error: the following arguments are required: video_file, output_file

Each time uv runs the script, it quickly checks that all listed dependencies are properly installed with their correct versions.

Another script I use this for is caption, which uses whisper (via the Open AI API) to quickly caption my screencasts just after I record and edit them. The caption quality very rarely need more than a very minor edit or two (for my personal accent of English at least) even for technical like “dunder method” and via the API the captions generate very quickly.

See the inline script metadata page of the Python packaging users guide for more details on that format that uv is using (honestly I always just copy-paste an example myself).

uv everywhere?

I haven’t yet fully embraced uv everywhere.

I don’t manage my Python projects with uv, though I do use it to create new virtual environments (with --seed to ensure the pip command is available) as a virtualenvwrapper replacement, along with direnv.

I have also started using uv tool as a pipx replacement and I’ve considered replacing pyenv with uv.

uv instead of pipx

When I want to install a command-line tool that happens to be Python powered, I used to do this:

1

$ pipx countdown-cli

Now I do this instead:

1

$ uv tool install countdown-cli

Either way, I end up with a countdown script in my PATH that automatically uses its own separate virtual environment for its dependencies:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ countdown --help
Usage: countdown [OPTIONS] DURATION

  Countdown from the given duration to 0.

  DURATION should be a number followed by m or s for minutes or seconds.

  Examples of DURATION:

  - 5m (5 minutes)
  - 45s (45 seconds)
  - 2m30s (2 minutes and 30 seconds)

Options:
  --version  Show the version and exit.
  --help     Show this message and exit.

uv instead of pyenv

For years, I’ve used pyenv to manage multiple versions of Python on my machine.

1

$ pyenv install 3.13.0

Now I could do this:

1

$ uv python install --preview 3.13.0

Or I could make a ~/.config/uv/uv.toml file containing this:

1

preview = true

And then run the same thing without the --preview flag:

1

$ uv python install 3.13.0

This puts a python3.10 binary in my ~/.local/bin directory, which is on my PATH.

Why “preview”? Well, without it uv doesn’t (yet) place python3.13 in my PATH by default, as this feature is currently in testing/development.

Self-installing Python scripts are the big win

I still prefer pyenv for its ability to install custom Python builds and I don’t have a preference between uv tool and pipx.

The biggest win that I’ve experienced from uv so far is the ability to run an executable script and have any necessary dependencies install automagically.

This doesn’t mean that I never make Python package out of my Python scripts anymore… but I do so much more rarely. I used to create a Python package out of a script as soon as it required third-party dependencies. Now my “do I really need to turn this into a proper package” bar is set much higher.

Learn Python by writing Python code ✍

We do not learn by putting information into the brain. Our brains simply don’t retain knowledge that way.

Learning happens from repeatedly attempting to retrieve information from the brain. When it comes to Python, that means writing Python code.

So unlike most Python courses, Python Jumpstart is not focused on watching videos and rewriting code seen within videos. Instead, this new Python course is based around learning Python by writing Python code.

How Python Jumpstart is structured 🔬

Python Jumpstart includes learning Python by solving 46 short Python exercises.

Before each exercise, you’ll watch a 5 minute video explaining a new Python topic. You’ll then attempt the exercise to put one or more Python topics into practice.

You won’t solve many of the exercises on your first try and that’s okay. These exercises are designed to be revisited a few times over the course of weeks, until you’re satisfied with your solution.

This is not a sprint 📆

This structured path to Python proficiency, includes:

• Carefully crafted exercises that build real understanding
• Short, detailed explanations that won’t waste your time
• A proven teaching approach that focuses on active learning
• Spaced repetition to help concepts stick

This is not a course for impatient or passive learners. Learning takes repetitive effort spaced over many days and this course is structured to embrace that fact.

If you spend 30 minutes on Python Jumpstart each day, I estimate that you’ll complete this course in about 7 weeks. You’ll spend the large majority of that time writing Python code.

This course will take time, but it will be time well-spent.

Launch week special: 50% off until December 2 ⏰

Through Monday December 2, 2024, you can get lifetime access to Python Jumpstart for $99. After this launch week, Python Jumpstart will be $199.

Ready to jumpstart your Python learning journey?

Get Python Jumpstart for $99

This is my seventh annual compilation of Python learning deals.

Lots of Python sales

Here are Python-related sales that are live right now:

• Python Jumpstart with Python Morsels: 50% off my brand new Python course, an introduction to Python that’s very hands-on ($99 instead of $199)
• Talk Python: the annual everything bundle includes all courses for $240
• Data School 40% off all Kevin’s courses or get a bundle with all 5 of his courses
• Matt Harrison: get 25% off with GIVING25 plus every purchase will open a product for a scholarship recipient
• Reuven Lerner: get 20% off Bamboo Weekly or 30% off any of his Weekly Python Exercise courses with code BF2024
• Brian Okken: is offering 20% off his courses with code TURKEYSALE2024
• Rodrigo 50% off Rodrigo’s all books bundle with code BF24
• Mike Driscoll: 35% off Mike’s Python books and courses with code BF24
• Test Driven: get the Flask course bundle for 30% off
• The Python Coding Place: 40% off The Python Coding Book and 40% off a lifetime membership to The Python Coding Place with code black2024
• Sundeep Agarwal: ~50% off Sundeep’s all book and Python bundles with code FestiveOffer
• Benjamin Bennett Alexander: 60% off his Mastering Python Fundamentals book with code BLACK60
• O'Reilly Media: 40% off the first year with code CYBERWEEK24 ($299 instead of $499)
• Matplotlib Journey: a Python dataviz course that has a pre-launch promo right now (69€ instead of 149€)
• Python Done Right: beta sale on this course ($99 instead of the eventual price of $299)
• Pragmatic Bookshelf: 40% off sale with code turkeysale2024
• No Starch: 35% off with code BLACKHATFRIDAY (Crash Course, Automate The Boring Stuff, etc.)
• Manning is offering 50% off if you buy two items

Even more sales

Also see Adam Johnson’s Django-related Deals for Black Friday 2024 for sales on Adam’s books, courses from the folks at Test Driven, Django templates, and various other Django-related deals.

And for non-Python/Django Python deals, see the Awesome Black Friday / Cyber Monday deals GitHub repository and the BlackFridayDeals.dev website.

If you know of another sale (or a likely sale) please comment below or email me.

Read more about Python Jumpstart

Want to read more about my new self-paced Intro to Python course that’s on sale? See this blog post on why I made Python Jumpstart and how it’s structured. Get it by Monday to save $100.

I’d like to share a secret feature within the Python 3.13 REPL which I’ve been finding useful recently: adding custom keyboard shortcuts.

This feature involves a PYTHONSTARTUP file, use of an unsupported Python module, and dynamically evaluating code.

In short, we may be getting ourselves into trouble. But the result is very neat!

Thanks to Łukasz Llanga for inspiring this post via his excellent EuroPython keynote talk.

The goal: keyboard shortcuts in the REPL

First, I’d like to explain the end result.

Let’s say I’m in the Python REPL on my machine and I’ve typed numbers =:

1

>>> numbers =

I can now hit Ctrl-N to enter a list of numbers I often use while teaching (Lucas numbers):

1

numbers = [2, 1, 3, 4, 7, 11, 18, 29]

That saved me some typing!

Getting a prototype working

First, let’s try out an example command.

Copy-paste this into your Python 3.13 REPL:

1
2
3
4
5
6
7
8
9
10
11

from _pyrepl.simple_interact import _get_reader
from _pyrepl.commands import Command

class Lucas(Command):

    def do(self):
        self.reader.insert("[2, 1, 3, 4, 7, 11, 18, 29]")

reader = _get_reader()
reader.commands["lucas"] = Lucas
reader.bind(r"\C-n", "lucas")

Now hit Ctrl-N.

If all worked as planned, you should see that list of numbers entered into the REPL.

Cool! Now let’s generalize this trick and make Python run our code whenever it starts.

But first… a disclaimer.

Here be dragons 🐉

Notice that _ prefix in the _pyrepl module that we’re importing from? That means this module is officially unsupported.

The _pyrepl module is an implementation detail and its implementation may change at any time in future Python versions.

In other words: _pyrepl is designed to be used by Python’s standard library modules and not anyone else. That means that we should assume this code will break in a future Python version.

Will that stop us from playing with this module for the fun of it?

It won’t.

Creating a PYTHONSTARTUP file

So we’ve made one custom key combination for ourselves. How can we setup this command automatically whenever the Python REPL starts?

We need a PYTHONSTARTUP file.

When Python launches, if it sees a PYTHONSTARTUP environment variable it will treat that environment variable as a Python file to run on startup.

I’ve made a /home/trey/.python_startup.py file and I’ve set this environment variable in my shell’s configuration file (~/.zshrc):

1

export PYTHONSTARTUP=$HOME/.python_startup.py

To start, we could put our single custom command in this file:

1
2
3
4
5
6
7
8
9
10
11
12
13

try:
    from _pyrepl.simple_interact import _get_reader
    from _pyrepl.commands import Command
except ImportError:
    pass  # Not in the new pyrepl OR _pyrepl implementation changed
else:
    class Lucas(Command):
        def do(self):
            self.reader.insert("[2, 1, 3, 4, 7, 11, 18, 29]")

    reader = _get_reader()
    reader.commands["lucas"] = Lucas
    reader.bind(r"\C-n", "lucas")

Note that I’ve stuck our code in a try-except block. Our code only runs if those _pyrepl imports succeed.

Note that this might still raise an exception when Python starts if the reader object’s command attribute or bind method change in a way that breaks our code.

Personally, I’d like to see those breaking changes occur print out a traceback the next time I upgrade Python. So I’m going to leave those last few lines without their own catch-all exception handler.

Generalizing the code

Here’s a PYTHONSTARTUP file with a more generalized solution:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

try:
    from _pyrepl.simple_interact import _get_reader
    from _pyrepl.commands import Command
except ImportError:
    pass
else:
    # Hack the new Python 3.13 REPL!
    cmds = {
        r"\C-n": "[2, 1, 3, 4, 7, 11, 18, 29]",
        r"\C-f": '["apples", "oranges", "bananas", "strawberries", "pears"]',
    }
    from textwrap import dedent
    reader = _get_reader()
    for n, (key, text) in enumerate(cmds.items(), start=1):
        name = f"CustomCommand{n}"
        exec(dedent(f"""
            class _cmds:
                class {name}(Command):
                    def do(self):
                        self.reader.insert({text!r})
                reader.commands[{name!r}] = {name}
                reader.bind({key!r}, {name!r})
        """))
    # Clean up all the new variables
    del _get_reader, Command, dedent, reader, cmds, text, key, name, _cmds, n

This version uses a dictionary to map keyboard shortcuts to the text they should insert.

Note that we’re repeatedly building up a string of Command subclasses for each shortcut, using exec to execute the code for that custom Command subclass, and then binding the keyboard shortcut to that new command class.

At the end we then delete all the variables we’ve made so our REPL will start the clean global environment we normally expect it to have:

1
2
3
4

Python 3.13.0 (main, Oct  8 2024, 10:37:56) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> dir()
['__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__']

Is this messy?

Yes.

Is that a needless use of a dictionary that could have been a list of 2-item tuples instead?

Yes.

Does this work?

Yes.

Doing more interesting and risky stuff

Note that there are many keyboard shortcuts that may cause weird behaviors if you bind them.

For example, if you bind Ctrl-i, your binding may trigger every time you try to indent. And if you try to bind Ctrl-m, your binding may be ignored because this is equivalent to hitting the Enter key.

So be sure to test your REPL carefully after each new binding you try to invent.

If you want to do something more interesting, you could poke around in the _pyrepl package to see what existing code you can use/abuse.

For example, here’s a very hacky way of making a binding to Ctrl-x followed by Ctrl-r to make this import subprocess, type in a subprocess.run line, and move your cursor between the empty string within the run call:

1
2
3
4
5
6
7
8
9
10
11
12

class _cmds:
    class Run(Command):
        def do(self):
            from _pyrepl.commands import backward_kill_word, left
            backward_kill_word(self.reader, self.event_name, self.event).do()
            self.reader.insert("import subprocess\n")
            code = 'subprocess.run("", shell=True)'
            self.reader.insert(code)
            for _ in range(len(code) - code.index('""') - 1):
                left(self.reader, self.event_name, self.event).do()
reader.commands["subprocess_run"] = _cmds.Run
reader.bind(r"\C-x\C-r", "subprocess_run")

What keyboard shortcuts are available?

As you play with customizing keyboard shortcuts, you’ll likely notice that many key combinations result in strange and undesirable behavior when overridden.

For example, overriding Ctrl-J will also override the Enter key… at least it does in my terminal.

I’ll list the key combinations that seem unproblematic on my setup with Gnome Terminal in Ubuntu Linux.

Here are Control key shortcuts that seem to be complete unused in the Python REPL:

• Ctrl-N
• Ctrl-O
• Ctrl-P
• Ctrl-Q
• Ctrl-S
• Ctrl-V

Note that overriding Ctrl-H is often an alternative to the backspace key

Here are Alt/Meta key shortcuts that appear unused on my machine:

• Alt-A
• Alt-E
• Alt-G
• Alt-H
• Alt-I
• Alt-J
• Alt-K
• Alt-M
• Alt-N
• Alt-O
• Alt-P
• Alt-Q
• Alt-S
• Alt-V
• Alt-W
• Alt-X
• Alt-Z

You can add an Alt shortcut by using \M (for “meta”). So r"\M-a" would capture Alt-A just as r"\C-a" would capture Ctrl-A.

Here are keyboard shortcuts that can be customized but you might want to consider whether the current default behavior is worth losing:

• Alt-B: backward word (same as Ctrl-Left)
• Alt-C: capitalize word (does nothing on my machine…)
• Alt-D: kill word (delete to end of word)
• Alt-F: forward word (same as Ctrl-Right)
• Alt-L: downcase word (does nothing on my machine…)
• Alt-U: upcase word (does nothing on my machine…)
• Alt-Y: yank pop
• Ctrl-A: beginning of line (like the Home key)
• Ctrl-B: left (like the Left key)
• Ctrl-E: end of line (like the End key)
• Ctrl-F: right (like the Right key)
• Ctrl-G: cancel
• Ctrl-H: backspace (same as the Backspace key)
• Ctrl-K: kill line (delete to end of line)
• Ctrl-T: transpose characters
• Ctrl-U: line discard (delete to beginning of line)
• Ctrl-W: word discard (delete to beginning of word)
• Ctrl-Y: yank
• Alt-R: restore history (within history mode)

What fun have you found in _pyrepl?

Find something fun while playing with the _pyrepl package’s inner-workings?

I’d love to hear about it! Comment below to share what you found.

You’re really looking forward to using the new REPL… but python manage.py shell just shows the same old Python REPL. What gives?

Well, Django’s management shell uses Python’s code module to launch a custom REPL, but the code module doesn’t (yet) use the new Python REPL.

So you’re out of luck… or are you?

How stable do you need your shell command to be?

The new Python REPL’s code lives in a _pyrepl package. Surely there must be some way to launch the new REPL using that _pyrepl package!

First, note the _ before that package name. It’s _pyrepl, not pyrepl.

Any solution that relies on this module may break in future Python releases.

So… should we give up on looking for a solution, if we can’t get a “stable” one?

I don’t think so.

My shell command doesn’t usually need to be stable in more than one version of Python at a time. So I’m fine with a solution that attempts to use the new REPL and then falls back to the old REPL if it fails.

A working solution

So, let’s look at a working solution.

Stick this code in a management/commands/shell.py file within one of your Django apps:

1
2
3
4
5
6
7
8
9
10

"""Python 3.13 REPL support using the unsupported _pyrepl module."""
from django.core.management.commands.shell import Command as BaseShellCommand


class Command(BaseShellCommand):
    shells = ["ipython", "bpython", "pyrepl", "python"]

    def pyrepl(self, options):
        from _pyrepl.main import interactive_console
        interactive_console()

How it works

Django’s shell command has made it very simple to add support for your favorite REPL of choice.

The code for the shell command loops through the shells list and attempts to run a method with that name on its own class. If an ImportError is raised then it attempts the next command, stopping once no exception occurs.

Our new command will try to use IPython and bpython if they’re installed and then it will try the new Python 3.13 REPL followed by the old Python REPL.

If Python 3.14 breaks our import by moving the interactive_console function, then an ImportError will be raised, causing us to fall back to the old REPL after we upgrade to Python 3.14 one day. If instead, the interactive_console function’s usage changes (maybe it will require arguments) then our shell command will completely break and we’ll need to manually fix it when we upgrade to Python 3.14.

What’s so great about the new REPL?

If you’re already using IPython or BPython as your REPL and you’re enjoying them, I would stick with them.

Third-party libraries move faster than Python itself and they’re often more feature-rich. IPython has about 20 years worth of feature development and it has features that the built-in Python REPL will likely never have.

If you’re using the default Python REPL though, this new REPL is a huge upgrade. I’ve been using it as my default REPL since May and I love it. See my screencast on Python 3.13 for my favorite features in the new REPL.

P.S. for Python Morsels users: if you want to try using that code module, check out the (fairly advanced) replr or (even more advanced) replsync exercises.

I’ve never seriously used direnv, but I’ve been hearing Jeff and Hynek talk about their use of direnv for a while.

After a few days, I’ve finally stumbled into a setup that works great for me. I’d like to note the basics of this setup as well as some fancy additions that are specific to my own use case.

My old virtualenvwrapper workflow

First, I’d like to note my old workflow that I’m trying to roughly recreate:

1. I type mkvenv3 <project_name> to create a new virtual environment for the current project directory and activate it
2. I type workon <project_name> when I want to workon that project: this activates the correct virtual environment and changes to the project directory

The initial setup I thought of allows me to:

1. Run echo layout python > .envrc && direnv allow to create a virtual environment for the current project and activate it
2. Change directories into the project directory to automatically activate the virtual environment

The more complex setup I eventually settled on allows me to:

1. Run venv <project_name> to create a virtual environment for the current project and activate it
2. Run workon <project_name> to change directories into the project (which automatically activates the virtual environment)

The initial setup

First, I installed direnv and added this to my ~/.zshrc file:

1

eval "$(direnv hook zsh)"

Then whenever I wanted to create a virtual environment for a new project I created a .envrc file in that directory, which looked like this:

1

layout python

Then I ran direnv allow to allow, as direnv instructed me to, to allow the new virtual environment to be automatically created and activated.

That’s pretty much it.

Unfortunately, I did not like this initial setup.

No shell prompt?

The first problem was that the virtual environment’s prompt didn’t show up in my shell prompt. This is due to a direnv not allowing modification of the PS1 shell prompt. That means I’d need to modify my shell configuration to show the correct virtual environment name myself.

So I added this to my ~/.zshrc file to show the virtual environment name at the beginning of my prompt:

1
2
3
4
5
6
7

# Add direnv-activated venv to prompt
show_virtual_env() {
  if [[ -n "$VIRTUAL_ENV_PROMPT" && -n "$DIRENV_DIR" ]]; then
    echo "($(basename $VIRTUAL_ENV_PROMPT)) "
  fi
}
PS1='$(show_virtual_env)'$PS1

Wrong virtual environment directory

The next problem was that the virtual environment was placed in .direnv/python3.12. I wanted each virtual environment to be in a .venv directory instead.

To do that, I made a .config/direnv/direnvrc file that customized the python layout:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

layout_python() {
    if [[ -d ".venv" ]]; then
        VIRTUAL_ENV="$(pwd)/.venv"
    fi

    if [[ -z $VIRTUAL_ENV || ! -d $VIRTUAL_ENV ]]; then
        log_status "No virtual environment exists. Executing \`python -m venv .venv\`."
        python -m venv .venv
        VIRTUAL_ENV="$(pwd)/.venv"
    fi

    # Activate the virtual environment
    . $VIRTUAL_ENV/bin/activate
}

Loading, unloading, loading, unloading…

I also didn’t like the loading and unloading messages that showed up each time I changed directories. I removed those by clearing the DIRENV_LOG_FORMAT variable in my ~/.zshrc configuration:

1

export DIRENV_LOG_FORMAT=

The more advanced setup

I don’t like it when all my virtual environment prompts show up as .venv. I want ever prompt to be the name of the actual project… which is usually the directory name.

I also really wanted to be able to type venv to create a new virtual environment, activate it, and create the .envrc file for my automatically.

Additionally, I thought it would be really handy if I could type workon <project_name> to change directories to a specific project.

I made two aliases in my ~/.zshrc configuration for all of this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

venv() {
    local venv_name=${1:-$(basename "$PWD")}
    local projects_file="$HOME/.projects"

    # Check if .envrc already exists
    if [ -f .envrc ]; then
        echo "Error: .envrc already exists" >&2
        return 1
    fi

    # Create venv
    if ! python3 -m venv --prompt "$venv_name"; then
        echo "Error: Failed to create venv" >&2
        return 1
    fi

    # Create .envrc
    echo "layout python" > .envrc

    # Append project name and directory to projects file
    echo "${venv_name} = ${PWD}" >> $projects_file

    # Allow direnv to immediately activate the virtual environment
    direnv allow
}

workon() {
    local project_name="$1"
    local projects_file="$HOME/.projects"
    local project_dir

    # Check for projects config file
    if [[ ! -f "$projects_file" ]]; then
        echo "Error: $projects_file not found" >&2
        return 1
    fi

    # Get the project directory for the given project name
    project_dir=$(grep -E "^$project_name\s*=" "$projects_file" | sed 's/^[^=]*=\s*//')

    # Ensure a project directory was found
    if [[ -z "$project_dir" ]]; then
        echo "Error: Project '$project_name' not found in $projects_file" >&2
        return 1
    fi

    # Ensure the project directory exists
    if [[ ! -d "$project_dir" ]]; then
        echo "Error: Directory $project_dir does not exist" >&2
        return 1
    fi

    # Change directories
    cd "$project_dir"
}

Now I can type this to create a .venv virtual environment in my current directory, which has a prompt named after the current directory, activate it, and create a .envrc file which will automatically activate that virtual environment (thanks to that ~/.config/direnv/direnvrc file) whenever I change into that directory:

1

$ venv

If I wanted to customized the prompt name for the virtual environment, I could do this:

1

$ venv my_project

When I wanted to start working on that project later, I can either change into that directory or if I’m feeling lazy I can simply type:

1

$ workon my_project

That reads from my ~/.projects file to look up the project directory to switch to.

Switching to uv

I also decided to try using uv for all of this, since it’s faster at creating virtual environments. One benefit of uv is that it tries to select the correct Python version for the project, if it sees a version noted in a pyproject.toml file.

Another benefit of using uv, is that I should also be able to update the venv to use a specific version of Python with something like --python 3.12.

Here are the updated shell aliases for the ~/.zshrc for uv:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

venv() {
    local venv_name
    local dir_name=$(basename "$PWD")

    # If there are no arguments or the last argument starts with a dash, use dir_name
    if [ $# -eq 0 ] || [[ "${!#}" == -* ]]; then
        venv_name="$dir_name"
    else
        venv_name="${!#}"
        set -- "${@:1:$#-1}"
    fi

    # Check if .envrc already exists
    if [ -f .envrc ]; then
        echo "Error: .envrc already exists" >&2
        return 1
    fi

    # Create venv using uv with all passed arguments
    if ! uv venv --seed --prompt "$@" "$venv_name"; then
        echo "Error: Failed to create venv" >&2
        return 1
    fi

    # Create .envrc
    echo "layout python" > .envrc

    # Append to ~/.projects
    echo "${venv_name} = ${PWD}" >> ~/.projects

    # Allow direnv to immediately activate the virtual environment
    direnv allow
}

Switching to starship

I also decided to try out using Starship to customize my shell this week.

I added this to my ~/.zshrc:

1

eval "$(starship init zsh)"

And removed this, which is no longer needed since Starship will be managing the shell for me:

1
2
3
4
5
6
7

# Add direnv-activated venv to prompt
show_virtual_env() {
  if [[ -n "$VIRTUAL_ENV_PROMPT" && -n "$DIRENV_DIR" ]]; then
    echo "($(basename $VIRTUAL_ENV_PROMPT)) "
  fi
}
PS1='$(show_virtual_env)'$PS1

I also switched my python layout for direnv to just set the $VIRTUAL_ENV variable and add the $VIRTUAL_ENV/bin directory to my PATH, since the $VIRTUAL_ENV_PROMPT variable isn’t needed for Starship to pick up the prompt:

1
2
3
4
5

layout_python() {
    VIRTUAL_ENV="$(pwd)/.venv"
    PATH_add "$VIRTUAL_ENV/bin"
    export VIRTUAL_ENV
}

I also made a very boring Starship configuration in ~/.config/starship.toml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

format = """
$python\
$directory\
$git_branch\
$git_state\
$character"""

add_newline = false

[python]
format = '([(\($virtualenv\) )]($style))'
style = "bright-black"

[directory]
style = "bright-blue"

[character]
success_symbol = "[\\$](black)"
error_symbol = "[\\$](bright-red)"
vimcmd_symbol = "[❮](green)"

[git_branch]
format = "[$symbol$branch]($style) "
style = "bright-purple"

[git_state]
format = '\([$state( $progress_current/$progress_total)]($style)\) '
style = "purple"

[cmd_duration.disabled]

I setup such a boring configuration because when I’m teaching, I don’t want my students to be confused or distracted by a prompt that has considerably more information in it than their default prompt may have.

The biggest downside of switching to Starship has been my own earworm-oriented brain. As I update my Starship configuration files, I’ve repeatedly heard David Bowie singing “I’m a Starmaaan”. 🎶

Ground control to major TOML

After all of that, I realized that I could additionally use different Starship configurations for different directories by putting a STARSHIP_CONFIG variable in specific layouts. After that realization, I made my configuration even more vanilla and made some alternative configurations in my ~/.config/direnv/direnvrc file:

1
2
3
4
5
6
7
8
9
10
11
12

layout_python() {
    VIRTUAL_ENV="$(pwd)/.venv"

    PATH_add "$VIRTUAL_ENV/bin"
    export VIRTUAL_ENV

    export STARSHIP_CONFIG=/home/trey/.config/starship/python.toml
}

layout_git() {
    export STARSHIP_CONFIG=/home/trey/.config/starship/git.toml
}

Those other two configuration files are fancier, as I have no concern about them distracting my students since I’ll never be within those directories while teaching.

You can find those files in my dotfiles repository.

The necessary tools

So I replaced virtualenvwrapper with direnv, uv, and Starship. Though direnv is doing most of the important work here. The use of uv and Starship were just bonuses.

I am also hoping to eventually replace my pipx use with uv and once uv supports adding python3.x commands to my PATH, I may replace my use of pyenv with uv as well.

Thanks to all who participated in my Mastodon thread as I fumbled through discovering this setup.

Python High Five is a 10-week Python jumpstart program that starts this September.

Set aside the time to learn ⌚

One of the biggest problems for folks starting to learn Python is setting aside the time. And even if you do manage to set aside the time, you’ll often hit a roadblock where you feel confused.

Python High Five is a way to keep a daily learning habit and to get help when find yourself stuck.

This program is based around daily practice. Monday through Friday you’ll pick 30 minutes from your schedule, at any time that works you. During those 30 minutes, you’ll watch a 5 minute video, work on the day’s exercise, and reflect on your progress.

The most effective learning is hands-on 🖐️

Python High Five is all about learning through writing Python code. Each week we’ll dive deeper into Python, building upon what we’ve learned so far.

When you find yourself stuck you can get help through an asynchronous group chat and weekly office hour sessions. In addition to our weekly office hours together, I’ll check the chat each day, respond to questions, and provide guidance.

Proven learning techniques behind the scenes 📝

The daily check-ins allow for daily accountability. The group chat also provides both a community of peers to rely on, and guidance from an experienced Python trainer (me).

We’ll also be using proven learning techniques behind the scenes:

• Retrieval practice: you don’t learn by putting information into your head, but by trying to take it out; for Python learning, that means writing code.
• Spaced repetition: cramming is less effective than learning spaced out over time, which is why we’ll spend 30 minutes each weekday instead of spending a few hours every week.
• Interleaving: each day’s exercise isn’t predictably themed because a bit of unpredictability can be really improve learning outcomes.
• Elaboration: your daily check-in isn’t just about reflection: it’s also a helpful learning tool!

Plus, we’ll be working through curriculum I’ve been developing and iterating on for many years. I have taught these topics in many different settings to folks from many different backgrounds.

Form a daily learning habit 🔁

Any 10-week program will be just the start of a Python learning habit. You’ll need to keep up your Python after Python High Five ends, either by promptly applying your skills to a new project or diving deeper into Python with continued daily practice.

That’s why I’m offering an 80% discount for High Five attendees on one year of Python Morsels, which is my skill-building service designed to help deepen your Python skills every week. You can see more details on that here.

Ready to start your Python journey? ⛰️

Are you ready to start your Python journey with a solid foundation?

Read more about Python High Five and decide whether this is for you.

Keep in mind that while the program begins on September 9, enrollment closes on August 31. So check the FAQs and if you have additional questions, be sure to email me soon!

I decided to make a tool that solves this problem for me: https://pym.dev/strptime

Finding the code to parse a date format with strptime

Here’s how I’m now using this new tool.

I find a date string in a random spreadsheet or log file that I need to parse. For example, the string 30-Jun-2024 20:09, which I recently found in a spreadsheet.

I then paste the string into the tool and watch the format appear:

Then I click on the date format to copy-paste it. That’s it!

This tool works by cycling through a number of common formats. It also works for dates without a time, like Jul 1, 2024.

This input field works great when you’re in need of a code for the datetime class’s strptime method (which parses dates). But what if you need a code for strftime (for formatting dates)?

Finding the code to format a date with strftime

If you don’t have a date but instead want to construct a date in a specific common format, scroll down the page a bit.

This page includes a table of common formats.

Click on the format to copy it. That’s it.

Playing with format codes

What if you have a date format already but you’re not sure what it represents?

Paste it in the box!

For example if you’re wondering what the %B in %B %d, %Y means, paste it in to see what that represent with the current date and time:

Other features

There are a few other hidden features in this tool:

• After a date or date format is pasted, if it corresponds to one of the formats listed in the table of common formats, that row will be highlighted
• Hitting the Enter key anywhere on the page will select the input field
• Clicking on a date within the format table will fill that date into the input box
• The bottom of the page includes links to other useful datetime formatting/parsing tools as well as a link to the relevant Python documentation

Thoughts? Feature requests?

What do you think of this tool?

Is this something you’d bookmark and use often? Is this missing a key feature that you would need for it to be valuable for your use?

Are there date and time formats you’d like to see that don’t seem to be supported yet?

Comment or email me to let me know!

Have you ever used Python’s json.tool command-line interface?

You can run python -m json.tool against a JSON file and Python will print a nicely formatted version of the file.

1
2
3
4
5
6
7

python -m json.tool example.json
[
    1,
    2,
    3,
    4
]

Why do we need to run json.tool instead of json?

The history of python -m

Python 3.5 added the ability to run a module as a command-line script using the -m argument (see PEP 338) which was implemented in Python 2.5. While that feature was being an additional feature/bug was accidentally added, alowing packages to be run with the -m flag as well. When a package was run with the -m flag, the package’s __init__.py file would be run, with the __name__ variable set to __main__.

This accidental feature/bug was removed in Python 2.6.

It wasn’t until Python 2.7 that the ability to run python -m package was re-added (see below).

The history of the json module

The json module was added in Python 2.6. It was based on the third-party simplejson library.

That library originally relied on the fact that Python packages could be run with the -m flag to run the package’s __init__.py file with __name__ set to __main__ (see this code from version 1.8.1).

When simplejson was added to Python as the json module in Python 2.6, this bug/feature could no longer be relied upon as it was fixed in Python 2.6. To continue allowing for a nice command-line interface, it was decided that running a tool submodule would be the way to add a command-line interface to the json package (discussion here).

Python 2.7 added the ability to run any package as a command-line tool. The package would simply need a __main__.py file within it, which Python would run as the entry point to the package.

At this point, json.tool had already been added in Python 2.6 and no attempt was made (as far as I can tell) to allow python -m json to work instead. Once you’ve added a feature, removing or changing it can be painful.

Could we make python -m json work today?

We could. We would just need to rename tool.py to __main__.py. To allow json.tool to still work also, would could make a new tool.py module that simply imports json.__main__.

We could even go so far as to deprecate json.tool if we wanted to.

Should we do this though? 🤔

Should we make python -m json work?

I don’t know about you, but I would rather type python -m json than python -m json.tool. It’s more memorable and easier to guess, if you’re not someone who has memorized all the command-line tools hiding in Python.

But would this actually be used? I mean, don’t people just use the jq tool instead?

Well, a sqlite3 shell was added to Python 3.12 despite the fact that third-party interactive sqlite prompts are fairly common.

It is pretty handy to have a access to a tool within an unfamiliar environment where installing yet-another-tool might pose a problem. Think Docker, a locked-down Windows machine, or any computer without network or with network restrictions.

Personally, I’d like to see python3 -m json work. I can’t think of any big downsides. Can you?

Update: pull request opened.

Too long; didn’t read

The “too long didn’t read version”:

• Python 2.5 added support for the -m argument for modules, but not packages
• A third-party simplejson app existed with a nice CLI that relied on a -m implementation bug allowing packages to be run using -m
• Python 2.6 fixed that implementation quirk and broke the previous ability to run python -m simplejson
• Python 2.6 also added the json module, which was based on this third-party simplejson package
• Since python -m json couldn’t work anymore, the ability to run python -m json.tool was added
• Python 2.7 added official support for python -m some_package by running a __main__ submodule
• The json.tool module already existed in Python 2.6 and the ability to run python -m json was (as far as I can tell) never seriously considered

All thanks to git history and issue trackers

I discovered this by noting the first commit that added the tool submodule to simplejson, which notes the fact that this was for consistency with the new json standard library module.

Thank you git history. And thank you to the folks who brought us the simplejson library, the json module, and the ability to use -m on both a module and a package!

Also, thank you to Alyssa Coghlan, Hugo van Kemenade, and Adam Turner for reviewing my pull request to add this feature to Python 3.14. 💖

Currently I have Kagi setup as my default search engine and I added a custom bang command in my Kagi account so that !x will trigger a search with Perplexity.

This got me thinking… could I trigger a new Chat GPT or Claude chat from my browser’s URL bar?

How browsers query search engines

Whether you’re using Chrome, Firefox, or some other browser (I’m trying Vivaldi) you can add custom search engines to your browser.

Custom search engines use a template URL that looks something like this:

https://duckduckgo.com/?q=%s

Note that this URL is a template because of that %s. That %s bit will be replaced by the actual query you search for.

So if Chat GPT and Claude have URLs that allow creating a new chat via a URL’s query string (the thing after the ?), then they could be used as search engines.

And it turns out… they do!

Querying Chat GPT via a URL

To query Chat GPT via a URL query string, use:

https://chatgpt.com/?q=%s

Set that URL as a custom “search engine” in your browser. Then whenever you’d like to start a new Chat GPT conversation, select your browser’s URL bar, type the search engine prefix followed by a space, type your query, and hit Enter!

Querying Claude via a URL

To query Claude via a URL query string, use:

https://claude.ai/new?q=%s

It works the same way as the Chat GPT URL.

Querying Perplexity via a URL

This may be a bit redundant, as you may have thought to use Perplexity can be used as a “search engine” in your browser, but here’s the URL in case you’re looking for it:

https://www.perplexity.ai/search?q=%s

Kagi bangs

If you’re a Kagi user, you can setup each of these as a custom bang.

Chat GPT

Claude

Perplexity

I’m not sure what bangs I ultimately want to use in the long-term. Right now I have !x set to query Perplexity, !c set to query Chat GPT, and !l set to query Claude.

I was considering !g for Chat GPT but that searches Google already and I was considering !c for Claude, but I had already set that to search Chat GPT, so I went with !l for Claude… or maybe it’s !l for LLM. 🤔

No Gemini “search” support

So Claude, Chat GPT, and Kagi can all initiate new conversations directly from your browser’s URL bar using these 3 URLs:

• https://chatgpt.com/?q=%s
• https://claude.ai/new?q=%s
• https://www.perplexity.ai/search?q=%s

As far as I can tell, Gemini does not support starting a conversation via a query string. Maybe this is related to Google embedding a similar feature directly into Chrome. 🤷

I loathe writing automated tests for performance-related exercises because they’re always flaky. How flaky depends on the exercise, what I’m testing, and the time variability inherent in the particular Python features that a learner might use.

I came up with a solution for flaky tests recently, but it also makes my tests less readable. I then came up with a tool to improve the readability, but that has its own trade-offs.

The code I eventually came up with is a beautiful Python monstrosity.

1
2
3
4
5
6

@attempt_n_times(10)
def _():
    nonlocal micro_time, tiny_time
    micro_time = time(micro_numbers)
    tiny_time = time(tiny_numbers)
    self.assertLess(tiny_time, micro_time*n)

I’ll explain what that code does, but first let’s talk about why it’s needed.

The flaky performance tests

My flaky performance tests initially looked like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def test_some_test(self):
    n, m = 2.45, 2.04

    micro_time = time(micro_numbers)
    tiny_time = time(tiny_numbers)
    self.assertLess(tiny_time, micro_time*n)

    small_time = time(small_numbers)
    self.assertLess(small_time, tiny_time*n)
    self.assertLess(small_time, micro_time*n*m)

    medium_time = time(medium_numbers)
    self.assertLess(medium_time, micro_time*n*m*m)
    self.assertLess(medium_time, tiny_time*n*m)
    self.assertLess(medium_time, small_time*n)

The first block runs a performance test for the user’s function on a very small list and on a slightly larger list and then asserting that the slightly larger list didn’t take too much longer to run. The next two blocks run the same code on even larger lists and make further assertions about the relative times that the code took to run.

This roughly approximates the time complexity of this code.

Running performance checks in a loop

These performance checks need to:

1. Predictably fail for inefficient solutions
2. Predictably pass for efficient solutions
3. Run fast (within just a few seconds) even when the code is inefficient
4. Avoid the use of threading because they’ll be running on WebAssembly in the browser
5. Run consistently on pretty much any computer

These 5 requirements together have caused me countless headaches. I get the tests passing well, but they don’t always fail when they should. I get the tests failing and passing when they should, but then they’re too slow. And so on…

Notice the n and m factors in the above assertions:

1

self.assertLess(small_time, micro_time*n*m)

If n and m are too big, we’ll get false positives (tests passing when they should fail). If n and m are too small, we’ll get false negatives (tests failing when they should pass).

To avoid both Type I and Type II errors, I decided to keep n and m small but attempt the assertion block multiple times.

Here’s the (far less flaky) revised code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

def test_some_test(self):
    n, m = 2.45, 2.04

    for attempts_left in reversed(range(10)):
        try:
            micro_time = time(micro_numbers)
            tiny_time = time(tiny_numbers)
            self.assertLess(tiny_time, micro_time*n)
            break
        except AssertionError:
            if attempts_left == 0:
                raise

    for attempts_left in reversed(range(5)):
        try:
            small_time = time(small_numbers)
            self.assertLess(small_time, tiny_time*n)
            self.assertLess(small_time, micro_time*n*m)
            break
        except AssertionError:
            if attempts_left == 0:
                raise

for attempts_left in reversed(range(3)):
    try:
        medium_time = time(medium_numbers)
        self.assertLess(medium_time, micro_time*n*m*m)
        self.assertLess(medium_time, tiny_time*n*m)
        self.assertLess(medium_time, small_time*n)
        break
    except AssertionError:
        if attempts_left == 0:
            raise

The for loop runs the code multiple times, the break statement stops the code as soon as the assertions all pass, and the except and if ensure that any assertion errors are suppressed until/unless we’re on the final iteration of the loop.

Let’s call this a for-try-break-except-if-raise pattern. It’s an absurdly verbose name fitting of absurdly verbose code.

This for-try-break-except-if-raise pattern works pretty well! But it’s not pretty.

Like many programmers, I believe that Don’t Repeat Yourself (DRY) need not apply to tests. Tests are allowed to be repetitive if the verbosity improves readability.

But there is so much noise in that code! I decided that removing some noise might improve readability. So I devised a helper utility to reduce the repetition.

In search of a solution

While pondering the repetitive noise in this code, I wondered what Python features I could use to abstract away this for-try-break-except-if-raise pattern.

Could I make a context manager and use a with block? That might help with the try-except, but context managers can’t run their code block multiple times, so that wouldn’t help with the for and the break. So a context manager is out.

Could I abstract this away into a looping helper by implementing a generator function? We are looping and generator functions can break early. But, a generator function can’t catch an exception that’s raised within the body of a loop. So a generator function wouldn’t work either.

What about a decorator? 🤔

Context managers and decorators both sandwich a block of code. But decorators sandwich functions and they have the power to run the same function repeatedly. A decorator might work!

Here’s a decorator that will run a given function up to 10 times (until no AssertionError is raised):

1
2
3
4
5
6
7
8
9

def try_10_times(function):
    def wrapper():
        for attempts_left in reversed(range(10)):
            try:
                return function()
            except AssertionError:
                if attempts_left == 0:
                    raise
    return wrapper

To use this decorator, we would need to define a function and then call that function:

1
2
3
4
5
6
7

@try_10_times
def assertions():
    micro_time = time(micro_numbers)
    tiny_time = time(tiny_numbers)
    self.assertLess(tiny_time, micro_time*n)

assertions()

This isn’t quite good enough though…

1. We need a pattern to run code N times (not necessarily exactly 10)
2. We reference the variables defined in each block in later blocks, so micro_time and tiny_time will need to be available outside that function
3. We need this function to run just one time right after it’s defined… could we do that automatically?

All 3 of these problems are solvable:

1. We need a decorator that accepts arguments
2. We need to use rarely seen nonlocal statement
3. We could have the decorator automatically call the decorated function

The final weird decorator

Here’s the decorator I ended up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def attempt_n_times(n):
    """
    Run tests multiple times if assertions are raised.

    Allows for more forgiving tests when assertions may be a bit flaky.
    """
    def decorator(function):
        """This looks like a decorator, but it actually runs the function!"""
        for attempts_left in reversed(range(n)):
            try:
                return function()
            except AssertionError:
                if attempts_left == 0:
                    raise
    return decorator

This decorator accepts an n argument which determines the maximum number of times the decorated function should be called. The decorator then calls the function repeatedly in a for loop and a try-except block. As soon as an AssertionError is not raised during one of these function calls, the looping stops.

The weirdest part about this decorator is that it calls the decorated function. Note that the decorator function doesn’t define a wrapper function within itself… it just runs code right away!

The resulting beautiful Python monstrosity

Here’s the final refactored test code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

def test_some_test(self):
    n, m = 2.45, 2.04
    micro_time = tiny_time = small_time = medium_time = 0

    @attempt_n_times(10)
    def _():
        nonlocal micro_time, tiny_time
        micro_time = time(micro_numbers)
        tiny_time = time(tiny_numbers)
        self.assertLess(tiny_time, micro_time*n)

    @attempt_n_times(5)
    def _():
        nonlocal small_time
        small_time = time(small_numbers)
        self.assertLess(small_time, tiny_time*n)
        self.assertLess(small_time, micro_time*n*m)

    @attempt_n_times(3)
    def _():
        nonlocal medium_time
        medium_time = time(medium_numbers)
        self.assertLess(medium_time, micro_time*n*m*m)
        self.assertLess(medium_time, tiny_time*n*m)
        self.assertLess(medium_time, small_time*n)

The attempt_n_times decorator immediately calls the function it decorates. Each function is defined and immediately called one or more times, in a try-except block within a loop.

That’s why we’ve named these functions with the throwaway _ name: we don’t care about the name of a function we’re never going to refer to again.

Also note the use of the nonlocal statement. Each function in Python has its own scope and all assignments assign to the local scope by default. That nonlocal variable pulls those variables to the scope of the outer function instead.

Compare the above code to the code just before this refactor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

def test_some_test(self):
    n, m = 2.45, 2.04

    for attempts_left in reversed(range(10)):
        try:
            micro_time = time(micro_numbers)
            tiny_time = time(tiny_numbers)
            self.assertLess(tiny_time, micro_time*n)
            break
        except AssertionError:
            if attempts_left == 0:
                raise

    for attempts_left in reversed(range(5)):
        try:
            small_time = time(small_numbers)
            self.assertLess(small_time, tiny_time*n)
            self.assertLess(small_time, micro_time*n*m)
            break
        except AssertionError:
            if attempts_left == 0:
                raise

    for attempts_left in reversed(range(3)):
        try:
            medium_time = time(medium_numbers)
            self.assertLess(medium_time, micro_time*n*m*m)
            self.assertLess(medium_time, tiny_time*n*m)
            self.assertLess(medium_time, small_time*n)
            break
        except AssertionError:
            if attempts_left == 0:
                raise

I find the refactored version easier to skim.

But that attempt_n_times decorator does abuse the decorator syntax. Decorators aren’t meant to call the function they’re decorating.

Is this misuse of decorators worth it?

Is this worth it?

Decorators aren’t supposed to immediately call the function they decorate. But there’s nothing stopping them from doing so. I feel that I’ve traded “normal code” for a beautiful monstrosity that’s easier to skim at a glance.

The attempt_n_times decorator is pretending that it’s a block-level tool by using a function because there’s no other way to invent such a tool in Python.

I think abstracting away the for-try-break-except-if-raise pattern was worth it, even though I ended up abusing Python’s decorator syntax in the process.

What do you think? Was that attempt_n_times abstraction worth it?

Attempting to eat vegan

Since 2020, I’ve been gradually eating more plant-based and a few months ago I decided to take PyCon as an opportunity to attempt exclusively vegan eating outside my own home. As I noted on Mastodon, it was a challenge and I failed every day at least once but I found the experience worthwhile. Our food system is very dairy-oriented.

Staying hydrated and fed

One of the first things I did before heading to the convention center was walk to Target and buy snacks and drinks. When at PyCon, I prefer to spend 30 minutes and $20 to have a backup plan for last minute hydration and calories (even if not the greatest calories). I never quite know when I might sleep through breakfast, find lunch lacking, or wish I’d eaten more dinner.

A tutorial, an orientation, a lightning talk, and open spaces

My responsibilities at PyCon this year included teaching a tutorial and helping run the Newcomer’s Orientation with Kojo and Sumana.

Yngve and Marie offered to act as teaching assistants during my tutorial and I was very grateful for their help! Rodrigo and Krishna also offered to TA just before my tutorial started and I was extra grateful to have even more help than I’d expected. The attendees were mostly better prepared than I expected they would be, which was also great. It’s always great to spend less time on setup and more time exploring Python together.

The newcomer’s orientation the next day went well. We kept it fairly brief and were able to address about 10 minutes of audience questions before the opening reception started.

Once my PyCon responsibilities completed, I invented a few more (light) responsibilities for myself. 😅 I signed up to give a lightning talk on how to give a lightning talk. They slotted it as the first talk of the first lightning talk session on Friday night. I kept this talk pretty much the same as the one I presented DjangoCon 2016. I could have made the transitions fancier, but I decided to embrace the idea of simplicity with the hope that audience members might think “look if that first speaker can give such a simple and succinct presentation, maybe I can too.”

On Saturday I ran an open space on Python Learning. Some of you showed up because you’re on my mailing list or you’re paying Python Morsels subscribers. Many folks showed up because the topic was interesting, either as a learner or as a teacher. I really enjoyed the round-table-style conversation we had.

I also ran a Cabo Card game open space during lunch on Sunday on the 4th floor rooftop. Cabo is my usual conference ice breaker game and I played it at least a few nights in The Westin lobby as well.

Seeing conference friends, old and new

For me, PyCon is largely about having conversations. The talks and tutorials are great for starting me thinking about an idea. The hallway track, open spaces, and meals are great for continuing conversations about those ideas (or other ideas).

My first morning in Pittsburgh, I chatted with Naomi and Reuven. I’m glad I ran into them before the conference kicked off because (as often happens at PyCon) I only very briefly saw either of them during the rest of PyCon!

After my tutorial that afternoon, I did dinner with Marie, Yngve, and Rodrigo at Rosewater Mediterranean (good vegan options, assuming you enjoy falafel and various sauces). As sometimes happens at PyCon, another PyCon attendee, Sachin, joined our table because we noticed him eating on his own at a table near us and invited him to join us.

On Saturday, Melanie, David, Jay, and I had a sort of mini San Diego Python study group reunion dinner before inviting folks to join us for Cabo and Knucklebones one night. The 4 of us originally met each other (along with Carol and other wonderful Python folks) at the San Diego Python study group about 10 years ago.

I had some wonderful conversations about ways to improve the Python documentation over dinner (at Nicky’s Thai) on Sunday night with so many docs-concerned folks who I highly respect. I’m really excited that Python has the documentation editorial board and I’m hopeful that that board, with the help of many others community members, will usher in big improvements to the documentation in the coming years.

I also met a number of Internet acquaintances IRL for the first time at PyCon. I met Tereza and Jessica, who I know from our work in the PSF Code of Conduct workgroup. I met Steve Lott, who I originally knew as a prolific question-answerer. I also met Hugo, a CPython core dev, the Python 3.14 & 3.15 release manager, and a social media user (which is how I’ve primarily interacted with him because the Internet is occasionally lovely). I was also very excited to meet many Python Morsels members as well as folks who know me through my weekly Python tips newsletter.

I was grateful to chat with Hynek and Al about creating talks, YouTube videos, and other online content. I also enjoyed chatting with Glyph a bit about our experiences consulting and training and (in hindsight) wished I’d planned an open space for either consultants or trainers, both of which have been held at PyCon before but it just takes someone to stick it on the open space board.

Many folks I only saw very briefly (I said a quick hi and bye to Andrew over lunch during the sprints) and some I didn’t see at all (Frank was at PyCon but we never ran into each other). Some I essentially saw through playing a few rounds of Cabo (Thomas and Ethan among many others). We also ran into at least 4 other PyCon attendees in the airport on Tuesday afternoon, including Bob and Julian, who it’s always a pleasure to see.

A Mastodon-oriented PyCon

On Thursday night I had the feeling that the number of Mastodon posts I saw on the #PyConUS hashtag was greater than the number of Twitter posts. I (very unscientifically) counted up the number of posts I was seeing on each and found that my perception was correct: Mastodon seemed to slightly overtake Twitter at PyCon this year.

Over dinner on Wednesday, I tried to convince Marie, Yngve, and Rodrigo to get Mastodon accounts just to follow the hashtag during PyCon. I succeeded: Marie and Yngve and Rodrigo!

Mastodon will never be the social media platform. Its decentralized nature is too much of a barrier for many folks. However, it does seem to be used by enough somewhat nerdy Python folks to now be one the most used social media platform for PyCon posting.

The talks

I ended up spending little time in the talks during PyCon. This wasn’t on purpose. I just happened to attend many open spaces, take personal breaks, and end up in hallway conversations often. I did see many of the lightning talks live, as well as Jay, Simon, and Sumana’s keynotes (all of them were exceptional) and the opening and closing remarks. I also watched a few talks from my hotel room while taking breaks.

While I’m often a bit light on my talk load at PyCon, I do recommend folks attend a good handful of live talks during PyCon, as Jon and others recommend. I wish I had seen more talks live. I also wish I had attended a few open spaces that I missed.

At any one time, I know that I’m always missing about 90% of what’s scheduled during PyCon (if you include the talks and the open spaces). That’s assuming I don’t ditch the conference entirely for a few hours and walk across a bridge or ride a funicular (neither of which I did, as I stuck around the venue the whole time this year). I am glad I saw, did, and talked about everything I did, but there’s always something I wish I’d seen/done!

The sprints

Thanks to the documentation dinner, I had a couple documentation-related ideas in mind on the first day of sprints. But I’m also really excited about the new Python REPL coming in Python 3.13 (in case you can’t tell from how much I talk about it), so I sprinted on that instead. Łukasz assigned me the task of researching keyboard shortcuts that the new REPL is missing (compared to the current one on Linux and Mac) so I spent some time researching that. I got to see the REPL running on Anthony’s laptop on Windows and I am so excited that Windows support will be included before 3.13.0 lands! 🎉

Partly inspired by Carol Willing’s PyCon preview message, I also thanked Pablo, Łukasz, and Lysandros in-person for all their work on the new Python REPL. 🤗

Until next year

I’ll be keynoting at PyOhio this year.

Besides PyOhio, I’m not sure whether I’ll make it to another conference until PyCon US next year. I’d love to attend all of them, but I do have work and personal goals that need accomplishing too!

I hope to see you at PyCon US 2025! In the meantime, if you’re wishing we’d exchanged contact details or met in-person, please feel free to stay in touch through Mastodon, LinkedIn, my weekly emails, YouTube, or Twitter.

Just before the feature freeze, a shiny new feature was added: a brand new Python REPL. ✨

This new Python REPL is the feature I’m most looking forward to using while teaching after 3.13.0 final is released later this year. In terms of improving my quality of life while teaching Python, this new REPL may be my favorite feature since f-strings were added in Python 3.6.

I’d like to share what’s so great about this new REPL and what additional improvements I’m hoping we might see in future Python releases.

None of these features will be ground breaking for folks who are already using IPython day-to-day. This new REPL really shines when you can’t or shouldn’t install PyPI packages (as when teaching a brand new Pythonistas in a locked-down corporate environment).

Little niceties

The first thing you’ll notice when you launch the new REPL is the colored prompt.

You may also notice that as you type a block of code, after the first indented line, the next line will be auto-indented! Additionally, hitting the Tab key inserts 4 spaces now, which means there’s no more need to ever hit Space Space Space Space to indent ever again.

At this point you might be thinking, “wait did I accidentally launch ptpython or some other alternate REPL?” But it gets even better!

You can “exit” now

Have you ever typed exit at the Python REPL? If so, you’ve seen a message like this:

1
2

>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit

That feels a bit silly, doesn’t it? Well, typing exit will exit immediately.

Typing help also enters help mode now (previously you needed to call help() as a function).

Block-level history

The feature that will make the biggest different in my own usage of the Python REPL is block-level history.

I make typos all the time while teaching. I also often want to re-run a specific block of code with a couple small changes.

The old-style Python REPL stores history line-by-line. So editing a block of code in the old REPL required hitting the up arrow many times, hitting Enter, hitting the up arrow many more times, hitting Enter, etc. until each line in a block was chosen. At the same time you also needed to make sure to edit your changes along the way… or you’ll end up re-running the same block with the same typo as before!

The ability to edit a previously typed block of code is huge for me. For certain sections of my Python curriculum, I hop into ptpython or IPython specifically for this feature. Now I’ll be able to use the default Python REPL instead.

Pasting code just works

The next big feature for me is the ability to paste code.

Check this out:

Not impressed? Well, watch what happens when we paste that same block of code into the old Python REPL:

The old REPL treated pasted text the same as manually typed text. When two consecutive newlines were encountered in the old REPL, it would end the current block of code because it assumed the Enter key had been pressed twice.

The new REPL supports bracketed paste, which is was invented in 2002 and has since been adopted by all modern terminal emulators.

No Windows support? Curses!

EDIT: This whole section is now irrelevant! During the PyCon US sprints in late May 2024, the readline and curses dependencies were removed and Windows support will be included in the second beta release of Python 3.13.0! 🎉

Unfortunately, this new REPL doesn’t currently work on Windows. This new REPL relies on the curses and readline modules, neither of which are available on Windows.

The in-browser Python REPL on Python Morsels also won’t be able to use the new REPL because readline and curses aren’t available in the WebAssembly Python build.

Beta test Python 3.13 to try out the new REPL 💖

Huge thanks to Pablo Galindo Salgado, Łukasz Langa, and Lysandros Nikolaou for implementing this new feature! And thanks to Michael Hudson-Doyle and Armin Rigo for implementing the original version of this REPL, which was heavily borrowed from PyPy’s pyrepl project.

The new Python REPL coming in 3.13 is a major improvement over the old REPL.

Want to try out this new REPL? Download and install Python 3.13.0 beta 1!

Beta testing new Python releases helps the Python core team ensure the final release of 3.13.0 is as stable and functional as possible. If you notice a bug, check the issue tracker to see if it’s been reported yet and if not report it!

Github notifications? 🤔

That pull request was quiet for many months, but in the last couple weeks, I started seeing email notifications in my inbox about it. I’ve never fancied myself a competent C developer and I try to steer clear from understanding TTY magic, so I have no idea what most of the commits do. But seeing activity on this pull request rejuvenated my excitement about this upcoming feature!

I also remember reading that the Python 3.13 feature freeze is coming up soon, so I’ve been silently cheering for that PR to make the cut before the deadline.

In the last few days, I decided that I should try committing to use this new REPL locally as my default Python environment. When I type python on my machine, I want to live in this new shiny REPL. I figure this will make it easier to spot bugs that might not have been noticed yet… though honestly it’ll mostly just allow me to try out this fancy new REPL first-hand.

Installing a custom CPython build in pyenv

I use pyenv to manage the many Python versions I have installed on my machine. I wondered whether it was possible to install a custom build of CPython with pyenv.

Instead of going to the pyenv documentation to figure out an answer, I argued with an AI until it gave me a working answer. I tried a few AI systems at first, but Claude seemed to give me the most promising-looking answer so it was the one I argued with for 5-10 minutes until I got a working solution.

First, I created this ~/.pyenv/plugins/python-build/share/python-build/3.13.0-pyrepl file:

1
2
3

prefer_openssl11
export PYTHON_BUILD_CONFIGURE_WITH_OPENSSL=1
install_package "pyrepl" "https://github.com/pablogsal/cpython/archive/pyrepl.tar.gz" standard verify_py39 ensurepip

Then I ran this command, which took a couple minutes:

1

$ pyenv install 3.13.0-pyrepl

After that, pyenv versions showed a new 3.13.0-pyrepl version:

1
2
3
4
5
6
7
8

$ pyenv versions
  system
* 3.8.18 (set by /home/trey/.pyenv/version)
* 3.9.18 (set by /home/trey/.pyenv/version)
* 3.10.13 (set by /home/trey/.pyenv/version)
* 3.11.6 (set by /home/trey/.pyenv/version)
* 3.12.0 (set by /home/trey/.pyenv/version)
  3.13.0-pyrepl

I then added 3.13.0-pyrepl to the top of my ~/.pyenv/version file to make this my default Python:

1
2
3
4
5
6

3.13.0-pyrepl
3.12.0
3.11.6
3.10.13
3.9.18
3.8.18

And it worked! Tying python showed the new colorful prompt.

Is is a bad idea to make this not-even-beta version of CPython the default Python on my machine? I have no idea. Everything’s been fine for the last 10 hours at least… 🤷

If you ever need to try installing a custom CPython build with pyenv, maybe the above instructions will work. They’re mostly generated by a large language model that didn’t give me a working answer until the third response… so feel free to let me know if it’s all wrong (or all right?).

After this adventure, I checked my podcast feed this evening only to realize that there’s a new core.py episode all about exactly this feature! If you’d like to hear some core developers nerd out about CPython development, give core.py a listen. You don’t need to understand how CPython development works to enjoy their enthusiasm. 💖

I left a few days into the PyCon US 2014 sprints and I remember feeling a bit like summer camp was ending. I’d played board games, contributed to an open source project, seen tons of talks, and met a ton of people.

My first Python conference: PyCon US 2014

PyCon 2014 was the first Python conference I attended.

At the start of the conference I only knew a handful of San Diegans. I left having met many more folks. Some of the folks I met I knew from online forums, GitHub repos, or videos I met Kenneth Love, Baptiste Mispelon, Carl Meyer, Eric Holscher in-person, among many others. Most folks I met I had never encountered online, but I was glad to have met in person.

For the most part, I had no idea who anyone was, what they did with Python, or what they might be interested in talking about. I also had no idea what most of the various non-talk activities were. I found out about the Education Summit and hadn’t realized that it required pre-registration. The open spaces are one of my favorite parts of PyCon and I didn’t even they existed until PyCon 2015.

I did stay for a couple days of the sprints and I was grateful for that. Most of the memorable human connections I had were during the sprints. I helped PyVideo upgrade their code base from Python 2 to Python 3 (this was before Will and Sheila stepped down as maintainers). Will guided me through the code base and seemed grateful for the help.

I also got the idea to write front-end JavaScript tests for Django during the sprints and eventually started that process after PyCon thanks to Carl Meyer’s guidance.

Attending regional conferences and DjangoCon

In fall 2014, I attended Django BarCamp at the Eventbrite office. That was my first exposure to the idea of an “unconference”… which I kept in mind when I spotted the open spaces board at PyCon 2015.

Before coming back to Montreal for PyCon 2015, I emailed Harry Percival to ask if he could use a teaching assistant during his tutorial on writing tests. His reply was much more enthusiastic than I expected: “YES YES OH GOD YES THANK YOU THANK YOU THANK YOU TREY”. I was very honored to be able to help Harry, as my testing workflow was heavily inspired by many blog posts he’d written about testing best practices in Django.

I coached at my first Django Girls event in 2015 in Ensenada and then my second at DjangoCon 2015 in Austin. I gave my first lightning talk at DjangoCon 2015, comparing modern JavaScript to Python. It was a lightning talk I had given at the San Diego JavaScript and San Diego Python meetups.

In 2016, I attended PyTennessee in Nashville. I remember attending a dinner of of about a dozen folks who spoke at the conference. I was grateful to get to chat with so many folks whose talks I’d attended.

Presenting talks and tutorials

I presented my first conference tutorial at PyCon 2016 in Portland and my first talk at DjangoCon US 2016 in Philadelphia. I had been presenting lightning talks every few months at my local Python and JavaScript meetups for a few years by then and I had hosted free workshops at my local meetup and paid workshops for training clients.

Having presented locally helped, but presenting on a big stage is always scary.

Volunteering

I volunteered at some of my first few conferences and found that I really enjoyed it. I especially enjoyed running the registration desk, as you’re often the first helpful face that people see coming into the conference.

During PyCon 2016, 2017, and 2018, I co-chaired the open spaces thanks to Anna Ossowski inviting me to help. I had first attended open spaces during PyCon 2015 and I loved them. Talks are great, but so are discussions!

I also ran for the PSF board of directors in 2016 and ended up serving on the board for a few years before stepping down. After my board terms, I volunteered for the PSF Code of Conduct working group for about 6 years. I didn’t even know what the PSF was until PyCon 2015!

A lot of travel… maybe too much

After DjangoCon 2016, I went a bit conference-wild. I attended PyTennessee 2017, PyCaribbean 2017 in Puerto Rico, PyCon US 2017 in Portland, PyCon Australia 2017 in Melbourne, DjangoCon 2017 in Spokane, PyGotham 2017 in NYC, and North Bay Python 2017 in Petaluma.

In 2018 I sponsored PyTennessee and PyOhio and spoke at both. I passed out chocolate chip cookies at PyTennessee as a way to announce the launch of Python Morsels. I also attended PyCon 2018 in Cleveland, DjangoCon 2018 in San Diego, PyGotham 2018, and North Bay Python 2018.

I slowed down a bit in 2019, with just PyCascades (Seattle), PyCon US (Cleveland), PyCon Australia (Sydney), and DjangoCon US (San Diego, which is home for me).

Since the pandemic

Since the start of the pandemic, I’ve attended PyCon US 2022, DjangoCon 2022 in San Diego (in my city for the third time!) and PyCon US 2023. Traveling is more challenging for me than it used to be, but I hope to attend more regional conferences again soon.

Between client work, I’ve been focusing less on conferences and more on blog posts (over here), screencasts, my weekly Python tips emails, and (of course) on Python Morsels.

My journey started locally

I became part of the Python community before I knew I was part of it.

I started using Python professionally in December 2009 and I attended my first San Diego Python meetup in March 2012. I met the organizers, gave some lightning talks, attended Saturday study group sessions (thanks Carol Willing, Alain Domissy, and others for running these), and volunteered to help organize meetups, study groups, and workshops.

By 2014, I had learned from folks online and in-person and I had helped out at my local Python meetup. I had even made a few contributions to some small Django packages I relied on heavily.

I was encouraged to attend PyCon 2014 by others who were attending (thanks Carol, Micah, and Paul among others). The conference was well-worth the occasional feeling of overwhelm.

We’re all just people

The biggest thing I’ve repeatedly learned over the past decade of Python conferences is that we’re all just people.

Carol Willing keynoted PyCon US 2023. But I met Carol as a kind Python user in San Diego who started the first Python study group meetings in Pangea Bakery on Convoy Street.

Jay Miller will be keynoting PyCon US 2024. But I met Jay as an attendee of the Python study group, who was enthusiastic about both learning and teaching others.

My partner, Melanie Arbor, keynoted DjangoCon 2022 along with Jay Miller. When I met Melanie, she was new to Python and was very eager to both learn and help others.

David Lord has made a huge impact on the maintenance of Flask and other Pallets projects. I met David as a Python study group attendee who was an enthusiastic StackOverflow contributor.

I learned a ton from Brandon Rhodes, Ned Batchelder, Russell Keith-Magee, and many others from online videos, forums, and open source projects before I ever met them. But each of them are also just Python-loving people like the rest of us. Russell gives good hugs, Ned is an organizer of his local Python meetup, and Brandon wears the same brand of shoes as me.

We all have people we’ve learned from, we suffer from feelings of inadequacy, we get grumpy sometimes, and we care about the Python language and community in big and small ways.

What’s next for you?

Will you attend a local meetup? Or will you attend an online social event?

If so, consider asking the organize if you can present a 5 minute lightning talk at a future event. As I noted in a DjangoCon 2016 lightning talk, lightning talks are a great way to connect with folks.

Will you attend a Python conference one day? See having a great first PyCon when/if you do.

Remember that we’re all just people though. Some may have a bit more experience (whether at speaking, contributing to open source, or something else), but we’re just people.

Lifetime Python Morsels access for the price of two years

I’m kicking things off with my sale on Python Morsels. Python Morsels helps developers deepen their Python skills in a way that day-to-day coding simply can’t.

Python Morsels is designed for:

• experienced developers frustrated with gaps in their Python knowledge
• self-taught programmers seeking courage and confidence in their Python abilities
• experienced Python developers hoping to dive even deeper

If you saw yourself in that list and you plan to use Python heavily for at least a few more years, I highly recommend checking out the Python Morsels sale.

From now through November 27, you can get lifetime access to Python Morsels for a one-time fee. Python Morsels usually costs $240/year but lifetime access is only $480. This is the best sale I’ve ever offered on Python Morsels and I’m guessing this might be the best Python-related deal this year.

💰 See the Python Morsels sale

On sale now

Here are Python-related sales that are live right now:

• Python Morsels: lifetime access to my Python skill-building platform for the price of 2 years
• O'Reilly Media: the first year is $200 off with the coupon CYBERWEEK23 ($299 instead of $499)
• Talk Python: 50% off 5 of their courses
• Data School: 40% off all Kevin Markham’s courses
• Brian Okken: 50% off pytest course and community access with coupon code BLACKFRIDAY (ends Nov 30)
• Reuven Lerner: 40% off Reuven’s courses and 25% off a new membership he’s launching
• Matt Harrison: 20% off Matt’s corporate training
• Sundeep Agarwal: around 70% off Sundeep’s all book and Python and his regex book is free
• Mike Driscoll: 33% off Mike’s Python books and courses with code black2023
• Stephen Gruppetta: 70% off pre-sale on his new Python membership ($95 instead of $395)
• Rodrigo: 40% discount on Rodrigo’s upcoming bootcamp and on his comprehensions course
• No Starch: 35% off with code DEALS4DAYS (Crash Course, Automate The Boring Stuff, etc.)
• Pragmatic Bookshelf: 40% off the pytest book and all other books with code turkeycode2023
• Manning 50% off eBooks, 40% off print books
• Udemy: various Python courses are on sale right now

If you know of another sale (or a likely sale) please comment below.

Django sales

Adam Johnson is also compiling many Django-related Black Friday and Cyber Monday sales via a Django sales post.

More developer-oriented deals

For even more Black Friday deals for software developers, see BlackFridayDeals.dev, which I believe launched this year.

Go get yourself some deals!

Go hop on those sales! (But make sure to put an event in your calendar to actually use what you purchase. 😉) And if you have questions about the Python Morsels Cyber Monday sale please comment below or email me.

Happy Python-ing!

• an experienced developer, frustrated with gaps in your Python knowledge
• a self-taught programmer seeking courage and confidence in your Python abilities
• or an intermediate-level Python learner trying to deepen your Python skills

…a weekly Python Morsels habit can help you make consistent progress and noticeable growth in just a few months.

Python Morsels is on sale through Cyber Monday. Subscribe now to save up to $108 per year.

Day-to-day coding isn’t purposeful learning

If you write Python frequently, you likely learn new things all the time. The learning you get from day-to-day coding is messy and unpredictable. Yes, learning happens, but gradually.

What if you could learn something unexpected about Python in just 30 minutes a week?

That’s what Python Morsels is designed to do: push you just outside your comfort zone to discover something new without requiring a big time sink.

The time I spent working on Python Morsels problems translates into saved time programming for work. And it’s not a grind - it’s actually fun. I’ve learned advanced Python concepts that I would have never had the opportunity to use in my day to day work.
— Eric Pederson, Python Morsels user

Guided Python practice every single week

Python Morsels is quite different from many other Python learning systems: you tell me your Python skill level (from novice to advanced) and I send you small tasks to help you sharpen your Python skills.

Every Monday, you’ll receive an email from me with:

• a short screencast to watch (or read)
• a multi-part exercise to move you outside your comfort zone (often achievable in 30 minutes)
• a mini exercise that you can accomplish in just 10 minutes
• links to dive deeper into subsequent screencasts and exercises

If you’d like to nudge your learning in a specific direction, you can always work through a topic-specific exercise path, or watch one of my many screencast series.

Does this actually work?

If you use Python Morsels even semi-regularly, I’m confident your Python skills will improve.

Here’s what Python Morsels users have to say:

I was hesitant about paying for Python Morsels given how many free learning resources there are. But it was definitely worth it. I’ve learnt more from Python Morsels than anything else, by far.
— Cosmo Grant

During my study of Python, I used various programming challenge sites. I can say for sure that this is the best challenge site I have ever come across.
— Bartosz Chojnacki

Not sure? Read more from Python Morsels users here.

Lock-in your $200/year subscription

Python Morsels currently includes over 150 screencasts and articles and nearly 200 exercises, each of which links to over a dozen helpful resources.

Subscribe before November 29, 2022 to lock-in your subscription at $200/year.

Subscribe to Python Morsels 💰

Save up to $108 a year on Python Morsels

Of course I’m going to kick things off with my own sale. 😉

Python Morsels helps developers deepen their Python skills in a way that day-to-day coding simply can’t.

Python Morsels is specifically crafted for:

• experienced developers frustrated with gaps in their Python knowledge
• self-taught programmers seeking courage and confidence in their Python abilities
• intermediate-level Python learners trying to deepen skills

If you saw yourself in that list, subscribe now before prices increase on November 29, 2022!

💰 See the Python Morsels sale

Python books, courses, templates, and exercises

There are a lot of Python-related sales going on this year. Note that some of the below sales include courses, some include books, some include templates (Itamar’s Docker templates for example) and some include a mix of different learning products.

• Reuven Lerner: Reuven’s Python courses are 40% off this week with the coupon BF2022
• Talk Python: Get all Talk Python courses in one $249 bundle
• Sundeep Agarwal: Sundeep’s all books bundle is 64% off (it’s $10), the Learn by example Python bundle is 80% off (it’s $3), and Practice Python Projects is free!
• Matt Harrison: Matt’s offering 30% off his Effective Pandas book on Friday only
• Itamar Turner-Trauring: Itamar’s Docker packaging products for Python are all 25% off through November with the code FALL22
• Mike Driscoll: Mike is offering $10 off any of his books this year with the coupon code black2022
• No Starch: books are 35% off with the coupon HOLIDAYDEALS
• Pragmatic Bookshelf: save 40% on Brian Okken’s PyTest book or any other Pragmatic Bookshelf book with the coupon code turkeysale2022
• Udemy: various Python courses are also on sale on Udemy right now, including Al Sweigart’s Automate the Boring Stuff with Python course

Python learning subscriptions

I use a subscription model for Python Morsels because subscriptions (when done well) can encourage habitual learning, which is often more effective than binge-learning. But Python Morsels isn’t the only subscription-based Python learning platform.

Here sales on other learning subscriptions:

• O'Reilly Media subscriptions are $200 off with the coupon CYBERWEEK22
• Dunder Data subscriptions (by Ted Petrou) are 40% off (normally $399), plus an extra 50% off for completing 3 certificates within 3 months
• DataCamp has a 50% off sale on their annual subscriptions right now as well

Also here’s a Python-related service that’s on sale (a subscription product, not a learning service):

• Sourcery: Sourcery Pro is 33% off for the first 12 months with coupon BLACKFRIDAY2022

Django sales

Adam Johnson compiled many Django-related Black Friday and Cyber Monday sales.

Here’s a quick summary:

• Will Vincent is offering 50% off a bundle for newer Django developers (sale)
• Adam Johnson is offering 50% off his books for experienced Django developers (announcement)
• Test Driven is selling a discounted bundle of courses on Django REST Framework, Celery, and search (sale)

Plus other discounted books, apps, templates, and services from others: read Adam’s full post for more details on the Django-related sales this year.

Go get yourself some deals!

Go hop on those sales! (But make sure to put an event in your calendar to actually use what you purchase. 😉)

And if you have questions about the Python Morsels Cyber Monday sale please comment below or email me.

Happy Python-ing!

In Python, variables and data structures don’t contain objects. This fact is both commonly overlooked and tricky to internalize.

You can happily use Python for years without really understanding the below concepts, but this knowledge can certainly help alleviate many common Python gotchas.

Table of Contents:

Terminology

Let’s start with by introducing some terminology. The last few definitions likely won’t make sense until we define them in more detail later on.

Object (a.k.a. value): a “thing”. Lists, dictionaries, strings, numbers, tuples, functions, and modules are all objects. “Object” defies definition because everything is an object in Python.

Variable (a.k.a. name): a name used to refer to an object.

Pointer (a.k.a. reference): describes where an object lives (often shown visually as an arrow)

Equality: whether two objects represent the same data

Identity: whether two pointers refer to the same object

These terms are best understood by their relationships to each other and that’s the primarily purpose of this article.

Python’s variables are pointers, not buckets

Variables in Python are not buckets containing things; they’re pointers (they point to objects).

The word “pointer” may sound scary, but a lot of that scariness comes from related concepts (e.g. dereferencing) which aren’t relevant in Python. In Python a pointer just represents the connection between a variable and an objects.

Imagine variables living in variable land and objects living in object land. A pointer is a little arrow that connects each variable to the object it points to.

This above diagram represents the state of our Python process after running this code:

1
2
3

>>> numbers = [2, 1, 3, 4, 7]
>>> numbers2 = [11, 18, 29]
>>> name = "Trey"

If the word pointer scares you, use the word reference instead. Whenever you see pointer-based phrases in this article, do a mental translation to a reference-based phrase:

• pointer ⇒ reference
• point to ⇒ refer to
• pointed to ⇒ referenced
• point X to Y ⇒ cause X to refer to Y

Assignments point a variable to an object

Assignment statements point a variable to an object. That’s it.

If we run this code:

1
2
3

>>> numbers = [2, 1, 3, 4, 7]
>>> numbers2 = numbers
>>> name = "Trey"

The state of our variables and objects would look like this:

Note that numbers and numbers2 point to the same object. If we change that object, both variables will seem to “see” that change:

1
2
3
4
5
6

>>> numbers.pop()
7
>>> numbers
[2, 1, 3, 4]
>>> numbers2
[2, 1, 3, 4]

That strangeness was all due to this assignment statement:

1

>>> numbers2 = numbers

Assignment statements don’t copy anything: they just point a variable to an object. So assigning one variable to another variable just points two variables to the same object.

The 2 types of “change” in Python

Python has 2 distinct types of “change”:

1. Assignment changes a variable (it changes which object it points to)
2. Mutation changes an object (which any number of variables might point to)

The word “change” is often ambiguous. The phrase “we changed x” could mean “we re-assigned x” or it might mean “we mutated the object x points to”.

Mutations change objects, not variables. But variables point to objects. So if another variable points to an object that we’ve just mutated, that other variable will reflect the same change; not because the variable changed but because the object it points to changed.

Equality compares objects and identity compares pointers

Python’s == operator checks that two objects represent the same data (a.k.a. equality):

1
2
3
4

>>> my_numbers = [2, 1, 3, 4]
>>> your_numbers = [2, 1, 3, 4]
>>> my_numbers == your_numbers
True

Python’s is operator checks whether two objects are the same object (a.k.a. identity):

1
2

>>> my_numbers is your_numbers
False

The variables my_numbers and your_numbers point to objects representing the same data, but the objects they point to are not the same object.

So changing one object doesn’t change the other:

1
2
3

>>> my_numbers[0] = 7
>>> my_numbers == your_numbers
False

If two variables point to the same object:

1
2
3

>>> my_numbers_again = my_numbers
>>> my_numbers is my_numbers_again
True

Changing the object one variable points also changes the object the other points to because they both point to the same object:

1
2
3
4
5

>>> my_numbers_again.append(7)
>>> my_numbers_again
[2, 1, 3, 4, 7]
>>> my_numbers
[2, 1, 3, 4, 7]

The == operator checks for equality and the is operator checks for identity. This distinction between identity and equality exists because variables don’t contain objects, they point to objects.

In Python equality checks are very common and identity checks are very rare.

There’s no exception for immutable objects

But wait, modifying a number doesn’t change other variables pointing to the same number, right?

1
2
3
4
5
6
7

>>> n = 3
>>> m = n  # n and m point to the same number
>>> n += 2
>>> n  # n has changed
5
>>> m  # but m hasn't changed!
3

Well, modifying a number is not possible in Python. Numbers and strings are both immutable, meaning you can’t mutate them. You cannot change an immutable object.

So what about that += operator above? Didn’t that mutate a number? (It didn’t.)

With immutable objects, these two statements are equivalent:

1
2

>>> n += 2
>>> n = n + 2

For immutable objects, augmented assignments (+=, *=, %=, etc.) perform an operation (which returns a new object) and then do an assignment (to that new object).

Any operation you might think changes a string or a number instead returns a new object. Any operation on an immutable object always returns a new object instead of modifying the original.

Data structures contain pointers

Like variables, data structures don’t contain objects, they contain pointers to objects.

Let’s say we make a list-of-lists:

1

>>> matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]

And then we make a variable pointing to the second list in our list-of-lists:

1
2
3

>>> row = matrix[1]
>>> row
[4, 5, 6]

The state of our variables and objects now looks like this:

Our row variable points to the same object as index 1 in our matrix list:

1
2

>>> row is matrix[1]
True

So if we mutate the list that row points to:

1

>>> row[0] = 1000

We’ll see that change in both places:

1
2
3
4

>>> row
[1000, 5, 6]
>>> matrix
[[1, 2, 3], [1000, 5, 6], [7, 8, 9]]

It’s common to speak of data structures “containing” objects, but they actually only contain pointers to objects.

Function arguments act like assignment statements

Function calls also perform assignments.

If you mutate an object that was passed-in to your function, you’ve mutated the original object:

1
2
3
4
5
6
7
8
9

>>> def smallest_n(items, n):
...     items.sort()  # This mutates the list (it sorts in-place)
...     return items[:n]
...
>>> numbers = [29, 7, 1, 4, 11, 18, 2]
>>> smallest_n(numbers, 4)
[1, 2, 4, 7]
>>> numbers
[1, 2, 4, 7, 11, 18, 29]

But if you reassign a variable to a different object, the original object will not change:

1
2
3
4
5
6
7
8
9

>>> def smallest_n(items, n):
...     items = sorted(items)  # this makes a new list (original is unchanged)
...     return items[:n]
...
>>> numbers = [29, 7, 1, 4, 11, 18, 2]
>>> smallest_n(numbers, 4)
[1, 2, 4, 7]
>>> numbers
[29, 7, 1, 4, 11, 18, 2]

We’re reassigning the items variable here. That reassignment changes which object the items variable points to, but it doesn’t change the original object.

We changed an object in the first case and we changed a variable in the second case.

Here’s another example you’ll sometimes see:

1
2
3
4

class Widget:
    def __init__(self, attrs=(), choices=()):
        self.attrs = list(attrs)
        self.choices = list(choices)

Class initializer methods often copy iterables given to them by making a new list out of their items. This allows the class to accept any iterable (not just lists) and decouples the original iterable from the class (modifying these lists won’t upset the original caller). The above example was borrowed from Django.

Don’t mutate the objects passed-in to your function unless the function caller expects you to.

Copies are shallow and that’s usually okay

Need to copy a list in Python?

1

>>> numbers = [2000, 1000, 3000]

You could call the copy method (if you’re certain your iterable is a list):

1

>>> my_numbers = numbers.copy()

Or you could pass it to the list constructor (this works on any iterable):

1

>>> my_numbers = list(numbers)

Both of these techniques make a new list which points to the same objects as the original list.

The two lists are distinct, but the objects within them are the same:

1
2
3
4

>>> numbers is my_numbers
False
>>> numbers[0] is my_numbers[0]
True

Since integers (and all numbers) are immutable in Python we don’t really care that each list contains the same objects because we can’t mutate those objects anyway.

With mutable objects, this distinction matters. This makes two list-of-lists which each contain pointers to the same three lists:

1
2

>>> matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
>>> new_matrix = list(matrix)

These two lists aren’t the same, but each item within them is the same:

1
2
3
4

>>> matrix is new_matrix
False
>>> matrix[0] is new_matrix[0]
True

Here’s a rather complex visual representation of these two objects and the pointers they contain:

So if we mutate the first item in one list, it’ll mutate the same item within the other list:

1
2
3
4
5

>>> matrix[0].append(100)
>>> matrix
[[1, 2, 3, 100], [4, 5, 6], [7, 8, 9]]
>>> new_matrix
[[1, 2, 3, 100], [4, 5, 6], [7, 8, 9]]

When you copy an object in Python, if that object points to other objects, you’ll copy pointers to those other objects instead of copying the objects themselves.

New Python programmers respond to this behavior by sprinkling copy.deepcopy into their code. The deepcopy function attempts to recursively copy an object along with all objects it points to.

Sometimes new Python programmers will use deepcopy to recursively copy data structures:

1
2
3
4
5
6
7
8
9

from copy import deepcopy
from datetime import datetime

tweet_data = [{"date": "Feb 04 2014", "text": "Hi Twitter"}, {"date": "Apr 16 2014", "text": "At #pycon2014"}]

# Parse date strings into datetime objects
processed_data = deepcopy(tweet_data)
for tweet in processed_data:
    tweet["date"] = datetime.strptime(tweet["date"], "%b %d %Y")

But in Python, we often prefer to make new objects instead of mutating existing objects. So we could entirely remove that deepcopy usage above by making a new list of new dictionaries instead of deep-copying our old list-of-dictionaries.

1
2
3
4
5

# Parse date strings into datetime objects
processed_data = [
    {**tweet, "date": datetime.strptime(tweet["date"], "%b %d %Y")}
    for tweet in tweet_data
]

We tend to prefer shallow copies in Python. If you don’t mutate objects that don’t belong to you you usually won’t have any need for deepcopy.

The deepcopy function certainly has its uses, but it’s often unnecessary. “How to avoid using deepcopy” warrants a separate discussion in a future article.

Summary

Variables in Python are not buckets containing things; they’re pointers (they point to objects).

Python’s model of variables and objects boils down to two primary rules:

1. Mutation changes an object
2. Assignment points a variable to an object

As well as these corollary rules:

1. Reassigning a variable points it to a different object, leaving the original object unchanged
2. Assignments don’t copy anything, so it’s up to you to copy objects as needed

Furthermore, data structures work the same way: lists and dictionaries container pointers to objects rather than the objects themselves. And attributes work the same way: attributes point to objects (just like any variable points to an object). So objects cannot contain objects in Python (they can only point to objects).

And note that while mutations change objects (not variables), multiple variables can point to the same object. If two variables point to the same object changes to that object will be seen when accessing either variable (because they both point to the same object).

For more on this topic see:

• My screencast series on Assignments and Mutation in Python
• Ned Batchelder’s Python Names and Values talk
• Brandon Rhodes' Names, Objects, and Plummeting From The Cliff talk

This mental model of Python is tricky to internalize so it’s okay if it still feels confusing! Python’s features and best practices often nudge us toward “doing the right thing” automatically. But if your code is acting strangely, it might be due to changing an object you didn’t mean to change.