Brian Okken and I recorded a podcast some time ago (September 2022) about my
scriv project and other adjacent
topics: Avoid merge conflicts on your
CHANGELOG with “scriv”.
We talked about:
- How scriv works
- The importance of keeping information in git (not just GitHub)
- The difference between commits and a changelog
- The value of hand-written changelogs
- Other projects of mine:
- Boston Python
- Versioning schemes: semver, calver, randver(!?)
Because this was recorded in September, a few things are slightly out of
date. I mention that Python 3.11 is coming out in October, but that meant last
October, not this year’s. When Brian asks me what else is going on, I don’t
mention the PyCon 2023
keynote, because I hadn’t even gotten the invitation back then.
It’s always a good time chatting with Brian.
Give it a listen.
A few weeks ago, I had the pleasure of delivering the opening keynote at
PyCon 2023. I’ve put up a text-and-slides version of the presentation:
People: The API User’s Guide. The video is not yet available, but it will be
When Mariatta invited me to do the keynote in January, I accepted, then knew
that I would have a hard time thinking about anything else for the three months
until the conference. My talk prep is always like this: I worry endlessly over
tiny details. The sentences I’m planning to say become earworms in my head. I
fiddle with the CSS of my HTML-based slides.
This period of preparation is stressful: I alternate between excitement at
how great it’s going to be, and anxiety because I have nothing useful to say, or
the flow is terrible and disjoint. When I express my worries, my wife says,
“your talks always go great,” and I respond, “but only because I worry about
In truth, I had started thinking about the ideas in this keynote about five
years ago. Literally some of the bubble chats on the slides existed in that
form in 2018. Over the years, I considered different ways of presenting them.
When the keynote invitation came, I knew I’d be talking about the People API
One of the most fun parts of preparing was working on the cartoons with
my son Ben. I’m constantly amazed at his
ability to craft a line that looks simple but expresses complex subtleties of
emotion. He’s a freelance illustrator, you should
Giving the talk was exhilarating, and I talked to so many people afterward
who liked it. PyCon is the kind of technical conference that welcomes
non-technical talks like this.
Afterward, it’s hard not to go over what I did on stage that was different
than planned. I ad-libbed a lot, some of it good, some of it meh. There were
things I intended to say that I forgot. But that is all in the past now. Other
types of performers have chances to do the same show multiple times, and so can
hone their performance. But I don’t know how they survive it: do they have
lines running through their head all the time? How do they ever set it
Once something like this is done, it’s difficult to predict where it will go.
In my experience, some talks reverberate and get recommended to others long
after they are done. Others seem good in the moment, but don’t echo much. Only
time will tell. Whatever happens, it was definitely a high-point for me.
I’m on the plane home from PyCon 2023 in Salt Lake City, thinking about the
last week. PyCon recaps often say the same things, and this is no exception,
but PyCon is an intense experience that should be noted. My notes here feel
a bit disjointed, but I’m trying to just relate some impressions, not craft a
In some ways, this was the expected PyCon experience: lots of friends old and
new, lots of good conversations, both technical and personal.
But this year was also different because I delivered the opening keynote. I
talked about How to Talk to People, which may seem like an odd keynote topic for
a technical conference, but that’s the way PyCon is: there’s a lot of discussion
of people and the interactions among them. (The video of the keynote isn’t
available yet, I’ll post it when it is.)
The Python community is not perfect. As with any large community, there is
conflict and drama, and not everyone stays. But the Python community is famous
for being more welcoming and inclusive than you’d expect for a technical
PyCon is the kind of technical conference that welcomes things like a keynote
about How To Talk To People. I had a lot of positive feedback, it was extremely
But even beside being a keynote speaker, there are dozens of unexpected but
authentic connections happening. A woman approached me and told me that in
2018, I saw her at PyCon and she seemed at loose ends, so I invited her to come
to dinner with our group. She said that now at every PyCon she remembers that
moment, because it was a tangible action that pulled her in and visibly welcomed
her as a specific individual.
Similarly, I had a chat with a well-known member of the community, a person
with a broad and visible presence in the Python world beyond the conference.
They said that they remember the time at a previous PyCon they were walking down
the hall, and I was sitting on a bench, and I called out to them by name, “as if
we were best friends,” as they put it. Again, that was a moment they felt they
moved from an outer ring more toward the center.
Of course, the only reason I knew who this person was back then was because
they had already been gaining visibility, but it’s easy for people to
underestimate the effect they are having on others. People don’t realize that
writing blog posts, or making podcasts, or publishing libraries is a way to be
known in the community. It may seem like a small activity when you are by
yourself making it or writing it, but people see it, and people start to know
In an open source world like Python, you don’t need a corporate marketing
department megaphone to make a difference. You don’t need to work at one of the
big sponsors to be “big.” If you do good work, people will start to know
This year Mariatta was the chair of the conference, and she brought an
intense authenticity to the plenaries. Each keynote was introduced with a
personal story about why she wanted to give that person the stage. She said I
wouldn’t remember, and I didn’t, that she and I first talked in the PyLadies
Slack workspace when she was anxious before her first presentation, and I told
her it was a good talk.
I’m telling these stories about reaching out to people not to pat myself on
the back, but to show that a small kindness to someone, even a “nobody,” can
have unexpected ripples across years. I said a small thing once to Mariatta and
it helped her take a first step that eventually led to her being a Python core
contributor and the chair of PyCon. You never know where things will lead.
For me that first interaction with Mariatta led to a keynote speech, and an
ice cream selfie:
I haven’t been to a PyCon since 2018. The vibe is the same: people working
together and collaborating. I talked to some attendees who contrasted it to
other tech conferences which felt more like a gathering of competitors. They
commented that even the big sponsors of PyCon (Meta, Google, Microsoft, etc.)
didn’t seem at odds with each other.
One thing that I kept noticing all weekend was people who were missing. I
kept remembering someone that I thought of as a fixture at PyCon who wasn’t
there. I don’t know if it’s because I haven’t been in five years, or if
lingering pandemic caution is keeping people home, or if it’s just the usual
conflicts with the rest of life.
I had chances to hang out with specific people I wanted to meet, and also
conversations with people I didn’t know until we started talking. Some
non-technical topics included the war in Ukraine, Christianity, cancer, as well
as less intense topics like comparative cuisine. It turns out people from
Brazil have never seen a tater tot (“is this made of rice?”).
One off-topic tradition continued:
spaces. We had one official one (posted on the board) Saturday, and another
impromptu one during the sprints on Monday. It’s a good ice-breaker to meet
people, and it’s fun to see both hidden talents and brave newbs trying it
I definitely should have had some Sleepy
Snake merch, because people asked me about my t-shirt a number of times. A
missed marketing opportunity!
One dynamic unique to our tail-of-the-pandemic times: I met two of my Boston
Python co-organizers in person for the first time in Salt Lake. Emily Charles
and Glenn Lehman both joined Boston Python during the pandemic and became
organizers, and I had never met them face-to-face before. We’ve had plenty of
good interaction over Zoom, so it was like meeting old friends for the first
time. But again, in our online open source world, that happens a lot. At least
one person said to me, “good to meet you; have we met before?”
One sprint day on Monday had a recurring dynamic that I always forget. I
think of coverage.py as
hard to get started with. But people show up willing to at least consider the
rock face with me, and we make a dent in some things. Even if the contributions
are small, at the very least it’s a chance to meet some new people and have some
nerd discussions along the way. Small contributions are helpful! Sitting with
people interested in the project gives me a chance to see it through new eyes,
and have some energy reflected back to me, recharging me to do some work on it
myself. Thanks to
the people who
joined me even when I disappeared for a few hours for ice cream and
A challenging aspect of PyCon is to make the most of your time there.
Another challenge is to somehow keep the energy going as you re-enter your
regular world, filled with other concerns and activities. If I come up with any
clever approaches, I’ll let you know.
I participated in the PyCascades sprint
day yesterday, offering up coverage.py as a
project. I was pretty sure it wasn’t beginner-friendly, but the sprint was
useful because it pointed out specific ways that it was not, and we fixed some
The sprint was all-remote, and we had about a half-dozen people online. They
dug in energetically, trying to set up a development environment. The first
thing we realized together was that the
Contributing page needed updating: it didn’t
mention making a GitHub fork, it over-emphasized virtualenvs without explaining
them, and it was too focused on specific versions of Python.
Phebe Polk fixed that with one of the merged pull requests for the day:
#1591 Update contribution instructions.
Another confusing point was that people might come to the coverage.py README
page with two different goals: people wanting to use the tool, and people
wanting to contribute to the tool. This may seem like a small point, but any
friction is worth eliminating, and it was done with a small
pull request by Kassandra Keeton.
Separately, Neil Pilgrim saw I had both a setup.cfg and pyproject.toml, so he
moved my pytest settings from the old-style file to the new:
build: Migrate pytest configuration to pyproject.toml.
One other problem people encountered was due to my docs build including
sphinxcontrib.spelling. That’s there for spell
checking, but it relies on an OS-native installation of enchant that most new
contributors won’t have. It was a simple matter to
use the extension only when spell checking, unblocking the default execution of
tox environments, and removing one more speed bump.
My biggest learning through this process was about hashed pins in my
dependency files. They are a security feature, but get in the way when people
install on different operating systems or versions of Python. I’m convinced now
they are a bad idea for coverage.py. I haven’t made any changes, but I
ranted in an issue about it. There are more details there
if you are interested.
I’m still eager to hear about people’s experience with starting to use
coverage.py or contribute to it. It’s not an easy project to make changes to,
but at least we can make it easier to get to the point of looking at the
The sprint didn’t go exactly in the direction I thought it would, but I
enjoyed talking over these issues with people, hanging out with them, and fixing
some friction points along the way.
I wrote a simple thing to watch the progress of GitHub Actions:
I started by using gh
run list, and tailoring the output, but that required running the command
obsessively to see the changes. Then I tried
gh run watch, but I
didn’t like the way it worked. You had to pick one action to watch, but my
branch has two actions that run automatically, and I need to know when both are
done. Plus, it lists all of the steps, which makes my complex action matrix
fill more than a screen, so I can’t even see the progress.
So I wrote my own. It buckets together the start times of the runs to
present them as a coherent run triggered by a single event. It keeps showing
runs as long as they have a new action to show. It presents the steps in a
compact form, and collapses jobs and runs once they succeed.
Give it a try and let me
know if it works for you.
A few days ago I posted Late initialization with mypy,
and people gave me feedback, and I realized they were right. The placebo
solution described there is clever, but too clever. It circumvents the value of
static type checking.
The comments on the blog post were telling me this, but what helped most was
a Mastodon thread with Glyph, especially when
I am using “correct” to say “type-time semantics consistently matching
The placebo works to say “there’s always a thing,” but it’s not a real thing.
A more useful and clearer solution is to admit that sometimes there isn’t a
thing, and to be explicit about that.
I actually took a slightly middle-ground approach. Some of the “sometimes”
attributes already had null implementations I could use, but I
removed all of the explicit “Placebo” classes.