Planet Python

Last update: October 02, 2026 10:48 AM UTC

October 02, 2026

Talk Python to Me

#565: Tachyon, Python 3.15's Built-in Sampling Profiler

Do you know what's actually slow in your Python app? Or are you guessing? Until now, profiling Python meant a tracing profiler that made your code 2 to 3 times slower. Or a third-party tool that broke with every new release. Python 3.15 fixes that. It ships Tachyon, a sampling profiler built into the standard library. It attaches to live production apps with almost zero overhead. My guests are Pablo Galindo Salgado, CPython core developer and Steering Council member, and László Kiss Kollár from Bloomberg's Python infrastructure team. Their first prototype ran at two samples a second. Now it does over a million hz. And it lands in Python 3.15 this October. Episode sponsors <a href='https://talkpython.fm/sentry'>Sentry Error Monitoring, Code talkpython26</a> <a href='https://talkpython.fm/devopsbook'>Python in Production</a> <a href='https://talkpython.fm/training'>Talk Python Courses</a> <h2 class="links-heading mb-4">Links from the show</h2> <div>Guests László Kiss Kollár: <a href="https://www.linkedin.com/in/lkollar/?featured_on=talkpython" target="_blank" >linkedin.com</a> Pablo Galindo Salgado 3.11: <a href="https://talkpython.fm/episodes/show/388/python-3.11-is-here-and-its-fast" target="_blank" >talkpython.fm</a> Memray: <a href="https://talkpython.fm/episodes/show/425/memray-the-endgame-python-memory-profiler" target="_blank" >talkpython.fm</a> PyStack: <a href="https://talkpython.fm/episodes/show/419/debugging-python-in-production-with-pystack" target="_blank" >talkpython.fm</a> profile and cProfile: <a href="https://docs.python.org/3/library/profile.html?featured_on=talkpython" target="_blank" >docs.python.org</a> py-spy: <a href="https://github.com/benfred/py-spy?featured_on=talkpython" target="_blank" >github.com</a> Austin: <a href="https://github.com/P403n1x87/austin?featured_on=talkpython" target="_blank" >github.com</a> PEP 799: <a href="https://peps.python.org/pep-0799/?featured_on=talkpython" target="_blank" >peps.python.org</a> PEP 768: <a href="https://peps.python.org/pep-0768/?featured_on=talkpython" target="_blank" >peps.python.org</a> PyCon US 2026 talk: <a href="https://us.pycon.org/2026/schedule/presentation/31?featured_on=talkpython" target="_blank" >us.pycon.org</a> The docs: <a href="https://docs.python.org/3.15/library/profiling.sampling.html?featured_on=talkpython" target="_blank" >docs.python.org</a> Backport to 3.14: <a href="https://github.com/pythonbackport/python-profiling?featured_on=talkpython" target="_blank" >github.com</a> Watch this episode on YouTube: <a href="https://www.youtube.com/watch?v=yZdfOf8kQo4" target="_blank" >youtube.com</a> Episode #565 deep-dive: <a href="https://talkpython.fm/episodes/show/565/tachyon-python-3.15s-built-in-sampling-profiler#takeaways-anchor" target="_blank" >talkpython.fm/565</a> Episode transcripts: <a href="https://talkpython.fm/episodes/transcript/565/tachyon-python-3.15s-built-in-sampling-profiler" target="_blank" >talkpython.fm</a> Theme Song: Developer Rap 🥁 Served in a Flask 🎸: <a href="https://talkpython.fm/flasksong" target="_blank" >talkpython.fm/flasksong</a> ---== Don't be a stranger ==--- YouTube: <a href="https://talkpython.fm/youtube" target="_blank" > youtube.com/@talkpython</a> Bluesky: <a href="https://bsky.app/profile/talkpython.fm" target="_blank" >@talkpython.fm</a> Mastodon: <a href="https://fosstodon.org/web/@talkpython" target="_blank" > @talkpython@fosstodon.org</a> X.com: <a href="https://x.com/talkpython" target="_blank" > @talkpython</a> Michael on Bluesky: <a href="https://bsky.app/profile/mkennedy.codes?featured_on=talkpython" target="_blank" >@mkennedy.codes</a> Michael on Mastodon: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" > @mkennedy@fosstodon.org</a> Michael on X.com: <a href="https://x.com/mkennedy?featured_on=talkpython" target="_blank" > @mkennedy</a> </div>

October 02, 2026 12:09 AM UTC

October 01, 2026

EuroPython

Humans of EuroPython: Diego Russo

This week we’d love to spotlight Diego Russo, a member of the Programme Team, and his contributions to EuroPython 2026.

In addition to helping ensure an interesting and varied conference programme, Diego was our liaison with Guido van Rossum, Łukasz Langa and Pablo Galindo Salgado who gave a very fun keynote session at the conference.

We&aposre so grateful for your contribution, Diego!

Cover image with Diego Russo, a member of the Programme Team at EuroPython 2026

EP: How were you involved in EuroPython 2026?

I was part of the Programme Team, managing the CfP, mentorship programme, speaker selection, waiting list and conference schedule. A big part of the work is keeping the programme balanced and free of gaps.

EP: Was there something specific about the Python community that made you want to give something back through volunteering?

I’ve used Python since 2006 and first attended EuroPython in Florence in 2011. I was struck by the community’s openness and welcoming spirit. Python conferences gave me a lot over the years, so in 2022 I decided to give something back by volunteering. Since then, I’ve worked with the Communications and Programme teams.

EP: What does the "invisible" side of EuroPython look like - the stuff that has to go right for everyone else to have a good time?

A lot of it is the schedule. We have several tracks and need to balance topics so people with different interests stay engaged. We receive far more proposals than we can fit, which lets us be selective but makes the choices difficult.

EP: What&aposs something you noticed about the conference because you were volunteering that you&aposd never have spotted as a regular attendee?

How many last-minute cancellations happen, and how quickly the team has to reshuffle the schedule and sometimes find replacement speakers during the conference itself.

EP: In what ways did volunteering shape or strengthen your ties to the community?

Python is more than a programming language to me. It has shaped my career to the point that I now contribute to CPython as a Core Developer, and the community played a major part in choosing that path.

EP: Is there a common myth about conference volunteering you&aposd like to set the record straight on?

I waited before volunteering because I thought I did not have enough experience. I was completely wrong. The EuroPython community made it easy to get involved from the start. If you are willing to help and learn, you gain experience along the way.

EP: What surprised you most about volunteering at EuroPython?

What surprised me most is how much volunteering changes the way you experience the conference. You stop seeing EuroPython only as an event you attend and start seeing the people, effort and collaboration that make it possible. It gives you a much stronger sense of belonging to the community.

EP: Thank you for your work, Diego!

October 01, 2026 11:56 PM UTC

Django Weblog

Nominate Someone for the 2026 Malcolm Tredinnick Memorial Prize

Hello Everyone 👋

It is that time of year again when we recognize someone from our community in memory of our friend Malcolm.

Malcolm was an early core contributor to Django and had a huge influence on the Django we know today. Besides being knowledgeable, he was also especially friendly to new users and contributors. He exemplified what it means to be an amazing Open Source contributor. We still miss him to this day.

The prize

Our prizes page summarizes it nicely:

The Malcolm Tredinnick Memorial Prize is a monetary prize, awarded annually, to the person who best exemplifies the spirit of Malcolm’s work - someone who welcomes, supports, and nurtures newcomers; freely gives feedback and assistance to others, and helps to grow the community. The hope is that the recipient of the award will use the award stipend as a contribution to travel to a community event -- a DjangoCon, a PyCon, a sprint -- and continue in Malcolm’s footsteps.

Please make your nominations using our form: 2026 Malcolm Tredinnick Memorial Prize nominations. Django Software Foundation board members, Django Fellows, and the Treasurer’s assistant are not eligible to receive the prize. You are still welcome to use the appreciation field below to recognize them, and we’ll make sure those messages are passed along.

We will take nominations until Saturday, October 15th, 2026, 23:59 Anywhere on Earth, and will announce the results in late October. If you have any questions, please use our dedicated forum thread or contact the DSF Board.

October 01, 2026 01:51 PM UTC

Python Insider

Python 3.10.22, 3.11.17, 3.12.15, 3.13.16 and 3.14.8 are now available!

Security updates across Python 3.10–3.14, the final maintenance release of 3.13, and a farewell to Python 3.10.

October 01, 2026 12:00 AM UTC

Graham Dumpleton

Getting to know Tachyon

Python 3.15 ships with a new profiler. It is called Tachyon, it lives in the standard library as the profiling.sampling module, and unlike cProfile it is a sampling profiler rather than a tracing one. I now have a set of hands-on workshops for it, which you can find at github.com/GrahamDumpleton/tachyon-workshops or on the workshops page of this site, and they have reached the point where I am happy for other people to do them. That said, they were not written for other people in the first place. They were written so I could learn Tachyon myself, and the reason I wanted to learn it had little to do with profiling as such.

Why I wrote them

For the past while I have been working on wrapture, a library built on top of wrapt for attaching bindings to arbitrary call sites in a Python program without modifying the code being observed, then doing something useful with what flows through those call sites, such as recording calls or exporting traces. Everything wrapture does happens from inside the process. It wraps functions, and when they are called it is there in the call path to see the arguments, the return value, the exception, and the time taken.

So when a profiler landed in the standard library the obvious question was whether wrapture could make use of it. Could Tachyon be offered as part of wrapture's tracing, so that a binding on a call site could also tell you what the program was doing underneath that call? Could the two share anything at all? I did not know, and reading the Tachyon documentation was not going to tell me, because the documentation describes what each option does and not what you would want it for. The only way I was going to get a real answer was to use every part of the profiler on real programs, and the way I have been doing that lately is to have workshops written for the thing I want to learn and then do the workshops.

Working from the outside

A sampling profiler does not instrument your program. Tachyon runs as a separate process, reads the call stack of the target process from the outside, a thousand times a second by default, and counts what it finds. The program runs at full speed and never knows it is being watched. The counts are then an estimate of where time went: a function that appears in half the samples took about half the time. cProfile, which in 3.15 has moved to profiling.tracing, does the opposite. It hooks every function call and return, so the counts are exact, but a program made of millions of small calls can run several times slower under it.

One of the early workshops puts the same program under both and the difference is stark enough that it answers the question of which to reach for most of the time. The other consequence of working from the outside is that the profiler needs permission to read another process's memory. Linux lets a user do that to processes they started themselves. macOS and Windows do not without root or administrator rights, which is why the workshops only run on Linux, and why on a Mac the way to run them is in a container. More on that below.

Where that leaves wrapture

My first impression, having now been through all of it, is that the two do not fit together. Tachyon works by looking in at a process from outside. wrapture works by being inside the process, in the call path. I have found nothing to suggest Tachyon can be driven from within the process it is profiling in the way wrapture would need, and nothing in the way it reads a process that a binding on a call site could hook into. The models are different enough that I cannot see a way of marrying them, at least not with what is in 3.15.

That is a perfectly good answer. I would rather know it now than have spent time trying to bolt one onto the other, and the reasoning behind it is grounded in having used every mode of the profiler rather than guessed from a page of options. If that changes in a later release, or if someone knows something about Tachyon's internals that I missed, I would like to hear about it. For now the question is parked, not closed.

Learning by having the lesson written

What surprised me was how much better this worked as a way of learning than reading the documentation would have. I did not write the workshops by hand. I described what I wanted each one to teach, had an AI build it, then did the workshop. The useful part was not that the AI knew Tachyon, since the documentation knew Tachyon just as well. It was that the AI kept filling in the context the documentation leaves out: why wall-clock time and CPU time disagree and what that disagreement tells you about the fix, why a view of which thread holds the GIL exists at all, why you would record a profile in the binary format and look at it later rather than looking at it now. Each feature came with a small program written to show it, which had the problem the feature was there to find, and that is what made the feature stick.

This is a different way to use an AI for learning than asking it questions. Asking questions gets you answers at the level of the question. Asking for the lesson to be built gets you something you then have to work through with your own hands, and if the lesson is wrong you find out when the check at the end of a step does not pass. It is also, I have noticed, far closer to how I actually learned things in the first place, which was by having to teach them.

What the workshops cover

There are two collections, with a catalog in the repository so that one URL offers both.

The first, "Profiling with Tachyon", is fourteen workshops and a little under four hours in total. It starts with running the profiler on a small report generator and reading the table it prints, so that you know what a sample is and why time is samples multiplied by an interval. It then puts a program under both the tracer and the sampler, and looks at how the profiler reads a process from outside and what that needs permission for. From there it moves through the pictures the profiler produces: the interactive flame graph, the heatmap that paints sample counts onto the source so a single expensive line stands out, and recording in the binary format to replay later as a table, a flame graph, a heatmap, a Firefox Profiler file, JSON lines or a pstats file. The next group is about choosing what to measure, with workshops on wall-clock against CPU time, threads and the GIL, the cost of exceptions, and async code profiled as tasks and awaits rather than as the event loop's stack. The last group looks closer, at the markers for native code and the garbage collector, at opcode-level profiling in the heatmap, at differential flame graphs for telling whether a fix worked, and at the live terminal view that watches one process like top.

The second, "Tachyon on real applications", is seven workshops and a little over two hours. Each one runs a realistic program in one terminal and drives it from a second, with the profiler between them. There is a Flask application under load, then a slow endpoint found with the flame graph, pinned to a line with the heatmap, fixed, and proven fixed with a second recording. There is a Starlette service under uvicorn whose searches stall when articles are read, including a fix with a thread that does not work and why, and one with a process pool that does. There are worker processes, both a process pool and gunicorn with three workers, profiled with --subprocesses. There is a pytest suite with the profiler wrapped around it, attaching to a server that was started without the profiler, and finally a profile recorded in production, carried back and compared in a notebook with a table and a chart.

Every workshop ships the program it profiles, and the flame graphs and heatmaps open in JupyterLab in a tab beside the code, so you are reading the picture and the source together rather than switching between a browser and an editor.

Running them

The workshops are built on jupyterlab-workshop, a JupyterLab extension that shows the instructions in a side panel with clickable actions that drive the session, opening files, running commands in a terminal and running cells in a notebook, and checks what you have done as you go.

The easiest way to start is the Binder button in the repository README, which builds the repository into a temporary JupyterLab on mybinder.org with nothing to install and no account needed. The session is thrown away when you are done, so finish a workshop in the session you started it in, and shut the session down from the Finish dialog or the File menu rather than just closing the tab, so the resources go back for other people. The Codespaces button does the same in a container tied to your GitHub account, which persists until you delete it and uses your account's monthly allowance.

If you want to run them on your own machine and that machine is a Mac, the Linux requirement means a container. The repository carries a Dockerfile for it, with Python 3.15, JupyterLab, the extension and a non-root user, and the checkout is mounted so everything the workshops write ends up in your checkout:

git clone https://github.com/GrahamDumpleton/tachyon-workshops
cd tachyon-workshops
docker build -t tachyon-workshops -f container/Dockerfile .
docker run --rm --init -it -p 127.0.0.1:8888:8888 -e JUPYTER_TOKEN=tachyon \
    -v "$PWD":/home/learner/tachyon-workshops tachyon-workshops

Then open http://127.0.0.1:8888/?token=tachyon. On Linux with Python 3.15 and uv you can skip the clone entirely and launch the extension on the catalog directly, with a directory of your own to keep the workshops in:

uvx --python 3.15 --from "jupyterlab-workshop[lab]" jupyter-workshop launch \
    --root ~/training --catalog https://raw.githubusercontent.com/GrahamDumpleton/tachyon-workshops/main/catalog.json

Python 3.15 is named because each workshop builds its own environment from the Python that JupyterLab runs on, and the profiler and the program it profiles must be the same Python. If you already have the extension installed somewhere, you can also just subscribe to the catalog from the workshop browser and the collections are offered there.

What's next

Whether Tachyon ends up having anything to do with wrapture, I know a good deal more about it than I did, and I have something to show for the time that other people can use. If you do the workshops and find a step that is unclear, or one that does not work for you, the issue tracker is the place to say so. Fingers crossed they are as useful a way into Tachyon for you as writing them was for me.

October 01, 2026 12:00 AM UTC

September 30, 2026

"Michiel's Blog"

Monitoring my Samsung smart washing machine without a cloud

Two weeks ago I gave a talk at Python Leiden on how I monitor my Samsung Smart washer without using Samsung SmartThings.

As Samsung announced using their SmartThings API will start costing USD 5 per month starting October, and today is the last day of September, I thought it would be appropriate to write a blog post based on my talk now.

I have a Samsung washing machine

My washing machine

I bought it in May 2021 for 450 euros. It plays Die Forelle whenever the wash is finished. But it’s in my garage, so I can’t hear it when I’m in my living room or home office. Also, it is “smart”. It calculates how long the cycle is going to take, depending on the load and I think also depending on how dirty the water is. This means that if you start a cycle, it tells you that it’s done in 90 minutes, and if you’d come back 90 minutes later it might still need 30 minutes, or it might be that it’s already done for 15.

It can send you notifications via the SmartThings app. This app requires a whole bunch of permissions, and takes up a whopping 857MB on my iPhone. It gets the data from the SmartThings cloud. So my washer talks to SmartThings, tells when it thinks the wash is done, and my phone talks to the same cloud if I open the app to see how the laundry is going and to send me notifications when it’s done. I don’t really like this much.

Samsung has just sent an update to some of their smart fridges bricking them for a couple of days. I don’t like that much either.

But you could use Home Assistant!

Yeah I know, Home Assistant. Every tinkerer’s favorite platform for home automation. Which you can install on a Raspberry Pi or on their own bespoke hardware. Indeed, it has a SmartThings integration. Unfortunately, this still works via Samsung’s cloud. So my washer still needs to talk to SmartThings, and my Home Assistant server would need to get its data from the Samsung Cloud. Moreover, Samsung decided to start asking money for the cloud access: 5 USD per month. As you see, it’s quite a popular integration too, with over 10% of Home Assistant users having this installed.

SmartThings warning Home Assistant

So if we calculate quickly, if I’d have paid 5 USD a month since I had this washer, it would have cost me €450 for the washer plus $320 for cloud access! That seems a little out of balance.

So what is my goal, anyway?

I would like to see when the wash is going to be ready. I’d want to have a small display that I can place in my living room that can show what is on the display of the washing machine, how many minutes are left. This way I can quickly estimate if I run an errand now or I’d wait until the wash is ready, first. I’d not want to use their app for this, nor their cloud.

My approach

I checked if there is any possibility for local access. I remembered when I read about the announcement of the Matter protocol, which would allow interoperability, and Samsung being one of the backers of this protocol, and me being happy about the fact that I bought a Samsung washer. Silly me.

It turns out Samsung indeed delivered Matter support. What they made is a feature where if you’d have a Matter lightbulb (or washer), you can control that from their SmartThings platform. But it does not work the other way around! My smart washer does not expose itself as a Matter device on the network. It does not expose any services on the network. Trust me, I used Wireshark!

This as opposed to my Brother printer, for instance, which has an open website and even an endpoint that exposes data as a .csv, which will happily show off how low the toner is, how many prints it made in its lifetime or even how many paper jams it had (a not insignificant amount).

Samsung could very easily have built something like that. But they don’t. Because they want me in their SmartThings ecosystem, sending my personal data, and possibly fetching my money, too.

So I decided to take an alternate approach: put a camera in front of the machine, take a picture, read it with computer vision, parse it and make it available over an HTTP endpoint on my local network. This turned out not to be so easy. Originally I was planning to use a Raspberry Pi that I still had lying around (who doesn’t have one?) with an old Logitech 720P webcam. But the webcam has a fixed focus distance, and a rather low resolution. It did not turn out well.

Low res

Then I decided to shell out for the Raspberry Pi Camera Module 3 which is the version that has autofocus. It is around 35 euros. And while it works well, only after I installed it I realized I could probably just as well have used an old Android phone with shattered screen. Because those also have decent cameras plus autofocus.

Higher res

And then I breadboarded together a Raspberry Pi Pico plus a 1602 LCD plus a buzzer, a few LEDs, and a push button. The Pico is a small programmable microcontroller that is great for things like this. It is low cost, runs MicroPython if you want, so what’s not to like? This display connects to wifi, gets the state of the washer and shows it on the screen. If there is no wash, it just acts as a clock. Pretty practical and I like it.

Pico with display

I needed the buzzer just so it could play Die Forelle when the laundry is ready ;-)

My thoughts

It would have been so much better if Samsung would have exposed this data on my wifi network!

Please note that this integration only allows me to read out the state of the washer, I can’t remote pause or add bubbles or whatever other features that are available via their app and that I would not ever use.

One of my coworkers explained he has a similar washing machine and he hooked it up to Home Assistant by simply connecting it to a smart plug that exposes the current draw. When there is no more current draw, he knows the washer is ready. This works, but my problem is that it does not help me with the question when the wash is going to be ready.

Because I now have the data, I could make a nice graph that shows the washing machine during its cycle adjusting the ETA a couple of times. Here’s an example of where it ended earlier than originally planned. But it can also end much later!

Washer countdown graph

I’d still like to print a 3D case for the display. And I thought that it might be nice if I’d actually expose a Matter service on my Pi, so one could integrate it in Home Assistant after all. However, I currently do not run Home Assistant myself and also as far as I could see there is no great Python library that I could use for this.

All in all, it was a fun project!

Discussion on Hacker News

September 30, 2026 08:00 PM UTC

Python Insider

Python Language Summit 2026

The 2026 Python Language Summit was hosted in Kraków, Poland as part of EuroPython 2026. There were 15 talks covering free-threading, Rust, garbage collection, type annotations, and more.

September 30, 2026 12:00 PM UTC

Lightning Talks (Python Language Summit 2026)

Lightning talks on a one-time ABI break, safer interruptions, EktuPy (Scratch but Python), an AGENTS.md file for CPython, and a call to read PEP 836.

September 30, 2026 12:00 PM UTC

PEP 827: Type Manipulation (Python Language Summit 2026)

Michael J. Sullivan presents PEP 827 and discusses a key design decision: how to store type annotations?

September 30, 2026 12:00 PM UTC

Free-Threaded Python Post-Era (Python Language Summit 2026)

Tobias Wrigstad, Fridtjof Stoldt, and Donghee Na propose a safe and performant, high-level concurrency model for free-threaded Python

September 30, 2026 12:00 PM UTC

Developer-in-Residence Update & Future (Python Language Summit 2026)

Petr Viktorin gives an update on the Developer-in-Residence role and asks Python core developers for projects to prioritize

September 30, 2026 12:00 PM UTC

Spicycrab (Python Language Summit 2026)

Kushal Das shows off Spicycrab, a Python-to-Rust transpiler for Python users who need performance without learning Rust or leaving Python

September 30, 2026 12:00 PM UTC

Rust for CPython (Python Language Summit 2026)

David Hewitt shares a status update, first module, and potential acceptance criteria for the Rust for CPython project

September 30, 2026 12:00 PM UTC

Memory Snapshots for CPython (Python Language Summit 2026)

Hood Chatham proposes memory snapshots and an initialization phase for speedier Python startups

September 30, 2026 12:00 PM UTC

Memory Buffer Protocol (Python Language Summit 2026)

Nathan Goldbaum proposes safe concurrent access through buffer leases and custom data types for the Python Buffer Protocol.

September 30, 2026 12:00 PM UTC

Garbage Collection: Generational? Incremental? Both! (Python Language Summit 2026)

Mark Shannon proposes a future garbage collection strategy for Python following the revert of the incremental garbage collector in Python 3.14

September 30, 2026 12:00 PM UTC

macOS and Python (Python Language Summit 2026)

Ned Deily weighs whether Python should continue shipping macOS installers

September 30, 2026 12:00 PM UTC

One namespace to namespace them all (Python Language Summit 2026)

Pablo Galindo Salgado proposes a top-level `std` namespace for the Python standard library to prevent module shadowing and free up module names.

September 30, 2026 12:00 PM UTC

Python Software Foundation

Python Language Summit 2026 blog posts are now available

On July 14th, 2026, 47 Python core developers and special guests sat down at the Python Language Summit, this year held in Kraków, Poland at EuroPython 2026, to discuss many topics about the future of the Python programming language, including free-threading, Rust, garbage collectors, type annotations, and namespacing.

Group photo of the attendees of the 2026 Python Language Summit Photo by EuroPython (CC BY-NC-SA 4.0)

This marked the first time the Python Language Summit had been hosted in Europe in 15 years, when the event was held in Florence on June 19th, 2011. Going forward, the Python Language Summit will alternate between PyCon US and EuroPython on a yearly basis.

The summit was organized by Emily Morehouse, Hugo van Kemenade, Lysandros Nikolaou, and Łukasz Langa, and blog posts were written by Seth Larson.

Below are summaries of the 10 full-length talks and 5 lightning talks that were presented at the 2026 Python Language Summit. I hope you enjoy them, and thank you for your patience.

“One namespace to namespace them all” by Pablo Galindo Salgado
“macOS and Python” by Ned Deily
“Garbage Collection: Generational? Incremental? Both!” by Mark Shannon
“Memory Buffer Protocol” by Nathan Goldbaum
“Memory Snapshots for CPython” by Hood Chatham
“Rust for CPython” by David Hewitt
“Spicycrab” by Kushal Das
“Developer-in-Residence Update & Future” by Petr Viktorin
“Free-Threaded Python Post-Era” by Donghee Na, Tobias Wrigstad, and Fridtjof Stoldt
“PEP 827: Type Manipulation” by Michael J. Sullivan
“Lightning Talks”
- “One-time ABI breakage” by Mark Shannon
- “Safer and Generic Interruptions” by Daniele Parmeggiani
- “EktuPy, Scratch but Python” by Kushal Das
- “AGENTS.md for CPython” by Gregory P. Smith and Łukasz Langa
- “Please read PEP 836 (JIT go brrr)” by Ken Jin

September 30, 2026 09:22 AM UTC

Python GUIs

Changing Ticks in PyQtGraph Objects to Strings — How to replace numeric axis ticks with custom labels like month names or dates in PyQtGraph

How do I replace the numeric tick labels on a PyQtGraph axis with custom strings, like month names or category labels?

When you're plotting data in PyQtGraph, the axes default to showing numeric tick values. That's fine for a lot of use cases, but sometimes your x-axis represents something more meaningful — like months of the year, days of the week, or category names. In those situations, you want to replace those numbers with readable string labels.

In this tutorial, you'll learn how to customize the tick labels on a PyQtGraph axis so they display strings instead of numbers.

How axis ticks work in PyQtGraph

PyQtGraph plots data using numeric values on both axes. When your x-axis data represents categories — like months — you typically use integers (1, 2, 3, ...) as placeholders and then map those integers to human-readable labels.

To do this, you need to:

Create a list of 2-tuples, where each tuple pairs a numeric tick position with a string label.
Get the axis object from the plot widget.
Call .setTicks() on that axis, passing your labels wrapped in a list.

Let's walk through a complete example.

Setting up the plot

We'll create a simple line plot showing temperature values across 10 months. The x-axis will use integers from 1 to 10 to represent months, and we'll replace those numbers with actual month names.

First, we generate the tick labels using Python's datetime module:

python

import datetime

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

month_labels = [
    (m, datetime.date(2020, m, 1).strftime("%B"))
    for m in months
]

This gives us a list like:

python

[(1, "January"), (2, "February"), (3, "March"), ...]

Each tuple maps a position on the x-axis (the integer) to a label (the month name). The strftime("%B") call converts a date into its full month name.

Applying the tick labels to the axis

Once you have your list of label tuples, you apply them to the bottom axis of the plot widget:

python

ax = self.graphWidget.getAxis("bottom")
ax.setTicks([month_labels])

Notice that month_labels is passed inside another list — so you're calling ax.setTicks([month_labels]), not ax.setTicks(month_labels). This is because setTicks() accepts a list of tick levels (for major ticks, minor ticks, etc.). By passing a single list inside the outer list, you're setting the major tick labels.

Complete working example

Here's the full application. You can copy and run this directly. If you're new to PyQtGraph, you may want to first read our introduction to plotting with PyQtGraph to understand the basics.

python

from PyQt6 import QtWidgets
from pyqtgraph import PlotWidget
import pyqtgraph as pg
import sys
import datetime


class MainWindow(QtWidgets.QMainWindow):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

        self.graphWidget = pg.PlotWidget()
        self.setCentralWidget(self.graphWidget)

        months = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
        temperature = [30, 32, 34, 32, 33, 31, 29, 32, 35, 45]

        self.graphWidget.setBackground("w")

        pen = pg.mkPen(color=(255, 0, 0))

        # Create a list of (tick_value, tick_label) tuples.
        month_labels = [
            (m, datetime.date(2020, m, 1).strftime("%B"))
            for m in months
        ]

        self.graphWidget.plot(months, temperature, pen=pen)

        # Get the bottom axis and apply our custom tick labels.
        ax = self.graphWidget.getAxis("bottom")
        ax.setTicks([month_labels])


app = QtWidgets.QApplication(sys.argv)
main_window = MainWindow()
main_window.show()
sys.exit(app.exec())

Running this produces a plot where the x-axis displays month names instead of numbers:

Plot with month name tick labels on the x-axis

Using any string labels

This approach works with any strings, not just month names. If you wanted to label the x-axis with arbitrary category names, you'd follow the same pattern:

python

labels = [
    (0, "Apples"),
    (1, "Oranges"),
    (2, "Bananas"),
    (3, "Grapes"),
]

ax = self.graphWidget.getAxis("bottom")
ax.setTicks([labels])

As long as you match each label string to the correct numeric position used in your data, the ticks will line up with your plot points.

If you want to plot time series data specifically, take a look at plotting time series data with PyQtGraph for a more detailed approach. You can also embed PyQtGraph into a larger custom widget for more complex applications, or combine it with Matplotlib plotting if you need additional chart types.

For an in-depth guide to building Python GUIs with PyQt6 see my book, Create GUI Applications with Python & Qt6.

September 30, 2026 06:00 AM UTC

Seth Michael Larson

Blogging for the Python Language Summit

Hey, did you miss me? I've only published two blog posts in the past two months because I was busy writing 10+ blog posts detailing the Python Language Summit in 2026. If you are interested in the Python programming languages' technical direction (or you just really miss my writing) go over to the Python Insider and read those write-ups.

I've been the blogger for the Python Language Summit for the past three years (2024, 2025, 2026). Before me, Alex Waygood was the blogger (2022, 2023), and he gave me guidance on what to expect from the Python Language Summit. Below is a mix of Alex's and my own guidance on what to expect as the Python Language Summit blogger.

What do you need to know as blogger?

It is useful to have some knowledge about the Python development process, ongoing concerns for the project, governance, and some history about "how we got to this moment" to be able to write about the Python Language Summit. You can prepare in-depth by looking at the topics that will be spoken about and reading the past few years of Python Language Summit blog posts, are there returning faces or themes? What have those people been up to in the meantime?

What topics do you know less about: research those ahead of time so once the jargon starts flying (because it will) that you're able to keep up. For example, I don't know much about Python's type annotations, but without fail there is a talk about this topic each year. I usually do the most research about this topic in particular to prepare.

Travel

You'll need to actually attend physically to cover the event. Figure out which conference the summit is colocated with (either PyCon US or EuroPython). If possible, I recommend if you are traveling into a drastically different timezone to arrive a few days early to give your body time to adjust. Taking technical notes during active discussions while you are extremely jet-lagged is not fun (ask me how I know).

The event itself is long (9:00AM to 5:30PM with breaks for coffee and lunch) and exclusively intense technical discussion. Come well-rested and drink plenty of water and caffeinated beverages.

People

The Python Language Summit is an in-person event and primarily compromised of attendees that are Python core team members or maintainers of alternate Python implementations or distributions. The past three years have seen between 45-50 attendees in the event.

Prior to 2024, I had never attended the Python Language Summit and only knew a few dozen of the hundreds of members from Python core team. Being able to put faces and voices to names is a challenge. Request the full list of attendees from the summit chairs before you attend, try to learn everyone on the list that you don't recognize beforehand.

On the day of the event, watch as people filter into the event before (and sometimes, during). Make a point to meet everyone and get names, talk for a bit, and make an association between their face, voice, and name. I like to draw out a "layout of the room", too, with reminders of people that I've just met and where they are sitting.

Usually the summit chairs ask for a round of introductions from everyone before starting the event, you can request that they do this to be sure.

It also helps to sit next to a summit chair, I've had to ask Hugo van Kemenade "who is speaking right now" a few times when it's difficult to know who has the microphone actively.

Recording and note-taking

The event is not video-recorded or audio-recorded (by default), so you won't be able to rely on anything that the event itself provides. Instead, you'll have to make a record of the event yourself and use that to recollect everything that happened and was said throughout the day.

I personally use "Voice Memos" from my phone to record the audio of the room and delete the recordings after they are no longer needed. The audio quality is so bad usually that you can't use automatic transcription software, instead you'll need to transcribe what everyone says by hand from the recording.

I also take extensive notes throughout the event. The important aspects to capture in your written notes is everything that wouldn't come across in a voice recording, like how does the energy of the room and conversations feel. Are people making faces, discussing amongst themselves, laughing and smiling? Note down all those moments, they give the write-ups life beyond a textual representation of what was said.

You'll also want to talk to people about the actual talks, ask them what a given topic has them thinking about, you can do this after the talks are over, too! You'll sometimes get a key insight or unearth a storyline or angle that you never would have known about from the talk itself: and then can clue-in the readers!

The attendees will tend to take some light notes in HackMD, but you should not rely on these notes for your purposes, they are not enough to be able to recreate the story and all the Q&A.

You should rely on the summit chairs and other attendees to take photos. There will be an album shared with everyone after the photos have be collected which you can pull from.

Slides

Ask the summit chairs to remind speakers to get slides. Follow-up with speakers a few days after the conference is over if you don't get them sent to you (and don't stop asking until you get them!) These slides are really useful for providing images in your write-ups. Especially code examples, which can be difficult to write down in real-time.

Writing

Alright, the language summit is over and now comes the hard part. Actually writing the blog posts! There are 10 talks and ~5 lightning talks. My rule of thumb is ~1000 words for each of the full-length talks and maybe ~300-500 words for each of the lightning talks. So you're looking at ~12,000 words total across the whole event.

I highly recommend getting as big a jump on the writing as soon as you can. Whether that's in the evenings of the conference itself or on the train/flight home. Use the energy you get from attending a community conference to carry you through! This was where I went wrong this year: I didn't prioritize finishing the writing as soon as I returned home, and that meant the blogs were two months after the event instead of only one month. Learn from me: finish your writing right away!

Publishing

After you're done with the drafts and are happy with the results, hand them over to the Language Summit chairs for proofreading. I recommend being specific about what kind of review you want at this stage: focus on fact-checking and finding typos, grammar, etc. After this review is complete, stage the blog posts on the Python Insider blog along with images. In 2026, I also published a landing page on the PSF blog.

Thanks for reading ♥ I would love to hear your thoughts! Contact me via Mastodon, Bluesky, or email. Browse the blog archive. Check out my blogroll.

September 30, 2026 12:00 AM UTC

September 29, 2026

PyCoder’s Weekly

Issue #754: Jev, PyO3, Temp Files, and More (2026-09-29)

#754 – SEPTEMBER 29, 2026
View in Browser »

How to Get Started With Jev in Python

Connect a Python script to the Jev model with the TypeSafe SDK and OpenRouter, then replace brittle input checks with Noul, Score, and Choice answers.
REAL PYTHON

Quiz: How to Get Started With Jev in Python

REAL PYTHON

MCP Auth That Passes the Security Review

When your customers connect AI agents to your product, their security team will have questions. PropelAuth has the answers built in: role-gated scopes, enterprise SSO through Okta and Entra ID, phishing-resistant consent screens, and an audit log of every agent connection. Learn More →
PROPELAUTH sponsor

How Libraries Run Rust Inside Python (With PyO3)

How do libraries run Rust inside Python? It all comes down to 4 steps: 1. Write Rust code, 2. Annotate it with PyO3 macros, 3. Let maturin compile and install it, 4. Import the result. See this in action for a hand-rolled JSON parser in this article.
BELDERBOS.DEV • Shared by Bob Belderbos

Creating Temporary Files in Python

How to create temporary files and directories in Python using the tempfile module’s NamedTemporaryFile and TemporaryDirectory.
TREY HUNNER

Articles & Tutorials

Navigating AI in Open Source: Insights From Wagtail

How should you manage AI contributions to an open-source project? How do you measure the impact of using AI tools for development, and what generative features do end users want from a content management system? This week on the show, we speak with Thibaud Colas and Meagen Voss from Wagtail about the complex considerations software organizations are currently facing.
REAL PYTHON podcast

How BMLL Processes 1.5 TB of Data in Under 4 Minutes

BMLL Technologies processes petabytes of nanosecond-precision market data for the world’s most sophisticated trading teams. In this case study, they share what a 48x performance improvement from Polars over pandas looks like in practice, and what it means for execution analysis at scale.
POLA.RS

Agent Memory for Wherever Your AI Is Running

Ship VectorAI DB to your edge device, factory floor, air-gapped facility, or enterprise data center and get a portable multimodal vector database that moves with your stack. Start on a laptop, validate retrieval quality against your workload, and promote the same pattern to production. Get Started Free →
ACTIAN sponsor

Python Statistics Fundamentals: How to Describe Your Data

In this step-by-step tutorial, you’ll learn the fundamentals of descriptive statistics and how to calculate them in Python. You’ll find out how to describe, summarize, and represent your data visually using NumPy, SciPy, pandas, Matplotlib, and the built-in Python statistics library.
REAL PYTHON

EVE Online Departs for Python 3

The game EVE has run on Python 2 since it launched in 2003, all 2.4 million lines of it, on a custom Stackless interpreter that stopped at 3.8. That is in the process of changing. Talk Python interviews three EVE developers about this process.
TALK PYTHON podcast

I Is for Immutable: Python a to Z

The first thing most people learn in programming is that you can save data in variables and change their values. For Juha-Matti, learning about immutable data structures and functional programming was a painful but important shift in schema.
JUHA-MATTI SANTALA

Your Personal Python Mentor

Real Python Mentor AI works alongside you. It sees the tutorial, lesson, or exercise you’re on, knows what you’ve been learning, and helps you understand, practice, and keep moving forward.
REAL PYTHON sponsor

7 Python Mistakes Beginners Make

Some mistakes are because Python did exactly what you asked it to do. This article covers seven of them. For each one you get the hidden cause, plus the first thing worth checking.
NAHLA DAVIES

Speeding Up a Python Service With CinderX

CinderX is Meta’s CPython extension: a method JIT, Static Python, and a parallel garbage collector. The article measures all three against stock CPython 3.14 and its tier 2 JIT
TIMOFEI IVANKOV

Cursor vs Copilot: Which AI Editor Is Better for Python?

Compare Cursor vs GitHub Copilot by building a Python project, testing agent workflows, debugging code, and evaluating AI-assisted development.
REAL PYTHON

Quiz: Cursor vs Copilot: Which AI Editor Is Better for Python?

REAL PYTHON

Using the Claude API in Python

Learn how to use the Claude API in Python to send prompts, control responses with system instructions, and get structured output.
REAL PYTHON course

Quiz: Using the Claude API in Python

REAL PYTHON

Projects & Code

pyfastlogging: A Lightning Fast Logger, Written in Rust

PYPI.ORG • Shared by Martin Bammer

Renart: A Local Workspace for SQL and Python Data Pipelines

GITHUB.COM/RENART-DATA • Shared by Lukas Senicourt

Pyxel Code Maker: Retro Python Games in Your Browser

KITAO.GITHUB.IO • Shared by Takashi Kitao

flowsint: Extensible Graph-Based Investigation Tool

GITHUB.COM/RECONURGE

bashautom: Persistent, Stateful Bash Sessions for Python

GITHUB.COM/HUSKAGO • Shared by Tiago

Events

Weekly Real Python Office Hours Q&A (Virtual)

Septempber 30, 2026
REALPYTHON.COM

Real Python Live: Release Radar: Python 3.15

Septempber 30, 2026
REALPYTHON.COM

Canberra Python Meetup

October 1, 2026
MEETUP.COM

Sydney Python User Group (SyPy)

October 1, 2026
SYPY.ORG

PyBay 2026

October 3 to October 4, 2026
PYBAY.ORG

PyCon Africa 2026

October 7 to October 12, 2026
PYCON.ORG

PyEducation: IPAF

October 8 to October 9, 2026
PYCON.ORG

Happy Pythoning!
This was PyCoder’s Weekly Issue #754.
View in Browser »

[ Subscribe to 🐍 PyCoder’s Weekly 💌 – Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]

September 29, 2026 07:30 PM UTC

Python Bytes

#498 A Tiny Episode

Topics covered in this episode: <ul> <li><a href="https://safedep.io/memtensor-sckit-worm-npm-pypi/?featured_on=pythonbytes">MemTensor / MemoryOS PyPI package hijacked via a malicious build backend</a></li> <li><a href="https://tinymongo.org?featured_on=pythonbytes">TinyMongo</a></li> <li>Jev: what to know</li> <li><a href="https://deadlovelll.github.io/2026-09-05-reading-dict-deoptimizes-attribute-access/?featured_on=pythonbytes">One innocent dict read makes attribute access permanently slower</a></li> <li>Extras</li> <li>Joke</li> </ul><a href='https://www.youtube.com/watch?v=OQp8W3krkrk' style='font-weight: bold;' data-umami-event="Livestream-Past" data-umami-event-episode="498">Watch on YouTube</a> About the show Sponsored by us! Support our work through: <ul> <li>Our <a href="https://training.talkpython.fm/?featured_on=pythonbytes">courses at Talk Python</a></li> <li>Consulting from <a href="https://sixfeetup.com/?featured_on=pythonbytes">Six Feet Up</a></li> </ul> Connect with the hosts <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy">Mastodon</a> / <a href="https://bsky.app/profile/mkennedy.codes?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/mkennedy?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/mkennedy/?featured_on=pythonbytes">LinkedIn</a></li> <li>Calvin: <a href="https://sixfeetup.social/@calvin?featured_on=pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/calvinhp.com?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/calvinhp?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/calvinhp/?featured_on=pythonbytes">LinkedIn</a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/pythonbytes.fm">BlueSky</a> / <a href="https://x.com/PythonBytes?featured_on=pythonbytes">X</a></li> </ul> Join us on YouTube at <a href="https://pythonbytes.fm/stream/live">pythonbytes.fm/live</a> to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to <a href="https://pythonbytes.fm/friends-of-the-show">our friends of the show list</a>, we'll never share it. Calvin #1: <a href="https://safedep.io/memtensor-sckit-worm-npm-pypi/?featured_on=pythonbytes">MemTensor / MemoryOS PyPI package hijacked via a malicious build backend</a> <ul> <li>On Sept 23 an attacker published backdoored MemoryOS 2.0.34 on PyPI and three bad versions (0.1.21, 0.1.23, 0.1.25) of MemTensor's OpenClaw plugin on npm. PyPI had no clean release that day, so 2.0.34 was the newest.</li> <li>They pushed commits to MemTensor's own GitHub Actions release pipelines. On PyPI that was a custom Poetry build backend, and on npm a tweaked validation script. Both used BASH_ENV to hand the publish token to the attacker before the real publish ran. SafeDep couldn't confirm how the attacker got push access.</li> <li>Runs on import, not install: A Go implant called sckit starts when the library loads, so --ignore-scripts won't save you.</li> <li>It harvests credentials from your home directory (npm and PyPI tokens, GitHub tokens, SSH keys, cloud CLI tokens, .env files) and sends them to skyleen[.]fr servers.</li> <li>It's a worm: It uses stolen tokens to copy itself into other repos and packages, so the victim list could grow.</li> <li>If you installed it: Downgrade to MemoryOS 2.0.33 (plugin 0.1.20) and rotate every credential reachable from $HOME. Also kill any running sckit stage0 process and check repos you can push to for a stray runtime-update.yml workflow or .sckit/ directory.</li> </ul> Michael #2: <a href="https://tinymongo.org?featured_on=pythonbytes">TinyMongo</a> <ul> <li>Want to use a MongoDB data interface, but swap out the storage engine? <ul> <li>Memory for testing/caching</li> <li>JSON/TinyDB simple JSON files</li> <li>SQLite for durable, high-perf reads with WAL</li> <li>SQLIte shared for high write apps</li> <li>DuckDB + Parquet for analytics apps</li> <li>Postgres + MariaDB for multi-machine client/server</li> </ul></li> <li>Great for teaching, examples, and simple deployments</li> <li><a href="https://github.com/schapman1974/tinymongo/issues/72?featured_on=pythonbytes">Amazing story of paired AI development</a> <ul> <li>Will completely run <a href="http://talkpython.fm?featured_on=pythonbytes">talkpython.fm</a> after weeks of shared work together (in SQLite mode).</li> </ul></li> </ul> Calvin #3: Jev: what to know <ul> <li>What it is: Jev is a model from TypeSafe AI that answers with typed results (yes/no probabilities, scores, picks from your options) instead of prose. <a href="https://realpython.com/jev-python/?featured_on=pythonbytes">Real Python published a hands-on tutorial on 2026-09-24</a> and the buzz on hacker news is almost deafening.</li> <li>It's proprietary: Jev is a hosted, closed-weight model. There are no weights to download and no self-hosting. Everything called "open Jev" is an independent reimplementation, not TypeSafe's model.</li> <li>Your data leaves your machine: Every call sends your input text to a third-party API. In the tutorial that path goes through OpenRouter to TypeSafe. Think twice before sending customer messages, tickets or anything sensitive.</li> <li>Cost and stability are open questions: The tutorial calls Jev "cheap, but not free" and says it's fast and cheap "at the moment." It also says whether that stays true is "something to keep an eye on."</li> <li>Credit to Real Python: It's a good, practical intro. It shows the Noul, Score and Choice primitives, and its point that instruction wording matters more than thresholds is useful advice for any model. The tutorial itself says similar results are possible with a well-prompted LLM.</li> <li>Open options to look at instead: <ul> <li>JevK5 (https://github.com/allebee/jevk5): Apache-2.0 weights and code, 4B or 9B parameters, and it accepts TypeSafe-style requests.</li> <li>SemIf, formerly OpenJev (https://github.com/TheoLeeCJ/openjev): MIT-licensed, small models, and it can run CPU-only.</li> <li>openjev-sglang (https://github.com/ekzhang/openjev-sglang): a Jev-compatible endpoint running Qwen3.6-35B-A3B, but no license is stated, so check before commercial use.</li> </ul></li> <li>The catch: These copy Jev's interface, not its model or training. Results will differ, and I haven't run any of them. Benchmarks are self-reported, and JevK5 is English-only.</li> </ul> Michael #4: <a href="https://deadlovelll.github.io/2026-09-05-reading-dict-deoptimizes-attribute-access/?featured_on=pythonbytes">One innocent dict read makes attribute access permanently slower</a> Timofei Ivankov benchmarks a CPython internals surprise: since 3.11, attribute access skips the instance dict entirely. A specialized opcode reads the attri.bute at a fixed byte offset in the object's inline values array. Read <code>obj.__dict__</code> once, though, and the dict gets materialized, the object loses that specialized path for the rest of its life, and a million-iteration loop goes from 33 ms to 51 ms on CPython 3.14. vars() and copy.copy() trigger the same thing, so a debugging print or a shallow copy in code touching your hot objects quietly makes every later attribute access roughly 1.5x slower. <ul> <li>The slowdown is permanent and nothing about it looks like a performance decision: ordinary code far from the hot loop can trigger it, and the function that gets slower never changes.</li> <li>Materializing dict produces a split table, and the LOAD_ATTR_WITH_HINT fallback declines split tables, so the object ends up with no specialization at all</li> <li>vars(), 'x' in o.dict, and copy.copy() all materialize it; copy.copy is the realistic trap since nobody treats a shallow copy as a performance decision</li> <li>slots instances read attributes at exactly the same speed and cannot fall into the trap since there is no dict to materialize</li> <li>On the free-threaded build both effects grow: atomic incref on reads plus an object lock on writes push the penalty from 17.6 to 25.4 ns</li> <li>Credit: this item was surfaced by the PyCoder's Weekly newsletter</li> </ul> Extras Calvin: <ul> <li><a href="https://pypi.org/project/whatsnewt/?featured_on=pythonbytes">whatsnewt</a> - a TUI text adventure through what's new in Python 3.15; playful but niche.</li> </ul> Joke: <a href="https://www.youtube.com/watch?v=xE9W9Ghe4Jk&t=323s">Shipping a button in 2026…</a>

September 29, 2026 06:08 PM UTC

eGenix.com

Python Meeting Düsseldorf - 2026-10-07

The following text is in German, since we're announcing a regional user group meeting in Düsseldorf, Germany.

Ankündigung

Das nächste Python Meeting Düsseldorf findet an folgendem Termin statt:

07.10.2026, 18:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Programm

Bereits angemeldete Vorträge

Philipp von dem Bussche:
Overengineering eines Fotobuchs: Meine Agenten-Reise durch Japans Sitzbezüge
Jens Diemer:
Radicle Explorer (LT)
Marc-André Lemburg:
Common shortcuts AI agents love to use
Jochen Wersdörfer:
AI coding harnesses
Klaus Bremer:
Monte Carlo Simulation und Concurrency mit Freethreading und Subinterpreters in Python 3.13 bis 3.15

Weitere Vorträge können gerne noch angemeldet werden. Bei Interesse, bitte unter info@pyddf.de melden.

Startzeit und Ort

Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden.

Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden.

Über dem Eingang steht ein großes "Schwimm’ in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt.

>>> Eingang in Google Street View

⚠️ Wichtig: Bitte nur dann anmelden, wenn ihr absolut sicher seid, dass ihr auch kommt. Angesichts der begrenzten Anzahl Plätze, haben wir kein Verständnis für kurzfristige Absagen oder No-Shows.

Einleitung

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet.

Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

Format

Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion.

Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit HDMI und FullHD Auflösung steht zur Verfügung.

(Lightning) Talk Anmeldung bitte formlos per EMail an info@pyddf.de

Kostenbeteiligung

Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet.

Tagungsraum, Beamer und Getränke produzieren Kosten. Daher bitten wir die Teilnehmer um eine Kostenbeteiligung in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.

Anmeldung

Da wir nur 25 Personen in dem angemieteten Raum empfangen können, möchten wir bitten, sich vorher anzumelden.

>>> Anmeldung bitte über den hierfür angelegten LinkedIn Event

Weitere Informationen

Weitere Informationen finden Sie auf der Webseite des Meetings:

https://pyddf.de/

Viel Spaß !

Marc-Andre Lemburg, eGenix.com

September 29, 2026 08:00 AM UTC

Armin Ronacher

Deser: Rethinking Rust Serialization

Serde is an amazing serialization library for Rust and it has been a huge reason why I felt productive with it for years. However already while at Sentry I got quite frustrated with some of the limitations with it but actually replacing Serde is tricky because of the might that it has in the ecosystem. Also because it’s quite hard to actually do better without also making some potentially painful compromises.

Here are three examples of Serde corner cases that show poor interactions of Serde features or unexpected limitations:

A number that is a map

An internally tagged enum, with serde_json‘s arbitrary_precision feature turned on:

#[derive(Deserialize)]
#[serde(tag = "type")]
enum Shape {
    Circle { radius: f64 },
}

serde_json::from_str::<Shape>(r#"{"type": "Circle", "radius": 1.5}"#)
// error: invalid type: map, expected f64

Serde’s data model has no place for arbitrary precision numbers, so serde_json uses in-band signalling with a map with a magic key. The enum has to buffer the fields until it has seen the tag, and the buffer does not know about the magic key. Because Cargo features are unified, it’s enough for any crate in your dependency graph to turn the feature on.

Flattening breaks integer keys

#[derive(Deserialize)]
struct Stats {
    scores: HashMap<u32, u32>,
}

#[derive(Deserialize)]
struct Report {
    name: String,
    #[serde(flatten)]
    stats: Stats,
}

serde_json::from_str::<Report>(r#"{"name": "x", "scores": {"42": 23}}"#)
// error: invalid type: string "42", expected u32 at line 1 column 35

Stats on its own parses {"scores": {"42": 23}} just fine. JSON keys are always strings, and serde_json only turns them into integers if the type asks for one. However once flatten buffers the value, "42" is just a string. The error also points at the end of the document rather than at the key.

Adapters do not compose

fn from_hex<'de, D: Deserializer<'de>>(d: D) -> Result<u32, D::Error> { ... }

#[derive(Deserialize)]
struct Theme {
    #[serde(deserialize_with = "from_hex")]
    primary: u32,
    #[serde(deserialize_with = "from_hex")]
    accent: Option<u32>,
}

//error[E0308]: `?` operator has incompatible types
//  |
//  |     #[serde(deserialize_with = "from_hex")]
//  |                                ^^^^^^^^^^ expected `Option<u32>`, found `u32`
//  |
//help: try wrapping the expression in `Some`
//  |
//  |     #[serde(deserialize_with = Some("from_hex"))]
//  |                                +++++          +

A function cannot be passed as a type parameter, so there is no way to apply from_hex to the inside of an Option, a Vec or a map. You write another function for every wrapper, and once you have from_opt_hex the field is no longer optional unless you also remember to add #[serde(default)].

None of these are bugs that are easy to fix in Serde. They fall out of its design, and that design is protected by Serde’s stability guarantees.

Back in 2022 I started an experiment called Deser. It’s a serialization library for Rust that takes the user experience of Serde and puts it on top of a completely different architecture inspired by miniserde. I never really finished it and it sat around for a few years. I picked it back up, and it has now reached a point where I think it’s worth looking at. Even just to inspire others to see if they want to explore the space.

The Name And Idea

The name is Serde with its two halves swapped. Deser is Serde but the other way around. In Serde, a type drives the deserialization process: a Deserialize impl asks the deserializer for the kind of value it expects, the format calls back into a visitor. Every nested value is handled by recursion which makes Serde deserialization inherently grow the stack with each level of nesting.

Deser on the other hand turns this around and the format tells the type of the next value and pushes events into a sink. When a sink hits the start of a nested value, it doesn’t call into it but hands back a new sink to a driver, which keeps all state on the heap (in fact, in an arena). On the way out, emitters return their nested values instead of recursing into them.

That also means that Deser cannot support formats like protobuf that are not self describing. They are in fact quite intentionally left out of the design entirely. Which is one way to say: if you want to “fix” Serde, you need to make some other compromises.

Most of the reasons for Deser’s ideas go back to Sentry Relay, which processes enormous amounts of untrusted JSON. Over the years when I was at Sentry we ran into the same set of problems again and again, and many of them are not really bugs in Serde but consequences of its design. Serde’s stability guarantees mean that a lot of them cannot be fixed without breaking every format and every hand written implementation. Most of these problems come from three decisions:

One set of traits for all formats. Serde serves both self describing formats (JSON, YAML, TOML, …) and formats where the reader has to know the type upfront (postcard, bincode, protobuf, …). That is incredibly useful, but it means that some features only work with some formats, and you find out at runtime. In case of Serde it also has some odd wrinkles where a derived struct quietly accepts an array in place of an object in JSON for instance.
A fixed data model that loses information when buffering. Internally tagged enums, untagged enums and flatten need to buffer values before they know what to do with them. The buffer can’t hold everything the format knew, errors lose their location and extensions to the ecosystem rely on in-band signalling to express things such as arbitrary precision numbers.
Recursion on the call stack. Every level of nesting uses stack space. Formats protect against this with a recursion limit, but the moment you go through a code path that doesn’t have one (writing, dynamic values), deeply nested data can take down your process. It also means that a deserialization cannot be paused while you wait for more input.

Many of the corresponding Serde issues have been open for years, and I wrote about abusing Serde before. People have tried different angles on this over the years. Some went minimal and dropped most features to get fast compiles and no recursion. dtolnay’s own miniserde is the best example of that, and deser’s trait design was originally modelled after it. Other recent attempts went for runtime reflection, or for a new data model with a focus on binary formats.

If you want to read up on all of the collected challenges with Serde’s design, I maintain a lengthy list here.

Dethroning Serde

First of all I don’t think it’s likely that one can replace Serde. The orphan rule entrenches Serde incredibly well in the ecosystem. But some things are within the reach of a crate author’s control. In case of Deser it’s completeness.

Deser today implements all important self describing formats from YAML, JSON, TOML, CBOR, JSON5 and the likes, but also XML and plist to really close the gap. XML in particular is something Serde has declined to support, and it shows (more on that below). At the very least format support should not be the reason not to use Deser.

The second problem usually is that actually solving Serde’s issues comes at a significant cost in compile time and/or runtime performance. Deser is no different. While Deser’s compile times are a bit better than Serde’s, the binary bloat is quite a bit worse and the runtime performance is mixed. It’s roughly comparable if you look at the numbers but depending on the format structure you are losing significantly from some of the tradeoffs.

That said, it’s now in a state where it’s at least in principle a drop-in replacement where the tradeoffs might work well for users.

Deser’s Design

Deser does not try to be significantly different than Serde on the surface level. For most uses you derive Serialize and Deserialize and then start using it with your format implementing crate of choice. Most attributes are very similar, though they are taking Rust expressions instead of strings.

use deser::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
#[deser(rename_all = "camelCase")]
pub struct Account {
    id: u64,
    account_holder: String,
    #[deser(default)]
    is_deactivated: bool,
}

let account: Account = deser_json::from_str(json)?;

The difference in the design would become more apparent if you implement a serializer or deserializer yourself. Instead of visitors that call into each other recursively, deserializing a type creates a sink which receives events that are directly emitted by the parser, and serializing produces emitters that hand out values. Nested sinks and emitters are handed back to a driver, which keeps them on the heap. This design, which is entirely stolen from miniserde, gives some interesting consequences:

No stack overflows. You can arbitrarily nest structures without issues. For untrusted input you set limits with a layer, and you pick the number that you are comfortable with, which is independent of your stack space.
Suspendable. Because the state lives in the driver, a deserialization can be fed input as it arrives. It’s also Send, so it can move between threads while you wait on IO which makes it much nicer to use with tokio. Formats like JSON, CBOR and MessagePack can be parsed as a stream if you so desire.
An extensible data model. The core data model is small and made of atoms, maps and sequences. For all else, there are extension values (DateTime, Uuid, etc.) that also all carry a fallback for formats that don’t understand them. Unlike Serde this means it does not rely on in-band signalling of objects with magic keys to smuggle values through.
Lossless buffering. When a value has to be buffered (for instance because the tag of an internally tagged enum comes last), Deser records the events together with everything the format knew about them. Protocol specific extension types or error locations all survive.
Layers are a middleware system that sit between the format and your types and can track things like paths, enforce safety limits, rename keys or redact values without having to touch specific code paths.
Native flattening that doesn’t buffer at all.

On top of that are a lot of things that I just wanted to have:

Allow enum tags to be of any type, not just strings
Adapters that compose (as = Option<Vec<DisplayFromStr>>)
Enabling validation as an adapter
derive attributes that are real Rust expressions instead of strings
bytes as a core functionality in the data model
duplicate keys rejected by default and errors that point at the problem

Here is a small configuration type that shows a few of these together:

use deser::adapters::DisplayFromStr;
use deser::de::Recording;
use deser::{Deserialize, Serialize};
use deser_encoding::Hex;
use deser_validate::{Check, NonEmpty, Range};
use ipnet::IpNet;

#[derive(Debug, Serialize, Deserialize)]
pub struct Config {
    // at least one 256-bit key, each written as hex
    #[deser(as = Check<NonEmpty, Vec<Hex>>)]
    secret_keys: Vec<[u8; 32]>,
    // `IpNet` knows nothing about deser, but has `FromStr` and `Display`
    #[deser(as = Option<Vec<DisplayFromStr>>)]
    allowed_networks: Option<Vec<IpNet>>,
    listeners: Vec<Listener>,
}

#[derive(Debug, Serialize, Deserialize)]
#[deser(tag = "type", rename_all = "snake_case")]
pub enum Listener {
    Unix { path: PathBuf },
    Tcp {
        host: IpAddr,
        #[deser(as = Check<Range<1, 65535>>)]
        port: u16,
    },
    // types this version does not know are kept and written back
    #[deser(other)]
    Other(#[deser(tag)] String, Recording),
}

Adapters are types, so Hex can go inside a Vec, and DisplayFromStr inside a Vec inside an Option. Validators are adapters too, so Check<NonEmpty, Vec<Hex>> decodes the keys and then checks that there is at least one. The catch-all variant keeps the tag and a recording of everything else in case someone wants to process it later.

Errors are something I care a lot about, so here is what happens when a value is wrong:

secret_keys = ["9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"]
allowed_networks = ["10.0.0.0/8", "fd00::/8"]

[[listeners]]
type = "unix"
path = "/run/app.sock"

[[listeners]]
host = "127.0.0.1"
port = 0
type = "tcp"

[[listeners]]
type = "quic"
host = "::1"
alpn = ["h3"]

let config: Config = deser_toml::Deserializer::from_str(input)
    .deserialize_with(|driver| driver.push_layer(PathLayer::new()))?;

Note that here the tag of the internally tagged enum comes last which means that the values have to be buffered until the tag is known. In Serde this is tricky and we would lose the location if we used some tricks to add it. With Deser however, with the path layer enabled Deser you where in the structure the problem is:

Unexpected: invalid value: must be between 1 and 65535 at line 10 column 8 (path: listeners[1].port)

Deser Meta Data

Deser really wants to be extensible, and XML is a more extreme example of the differences between Deser and Serde. Here is an Atom entry that mixes in Dublin Core for the authors:

use chrono::{DateTime, Utc};
use deser::Deserialize;
use deser_value::Value;
use deser_xml::DeserializerConfig;

deser_xml::namespace!(
    atom = "http://www.w3.org/2005/Atom",
    dc = "http://purl.org/dc/elements/1.1/",
);

#[derive(Debug, Deserialize)]
struct Entry {
    #[deser(rename = atom!("title"))]
    title: String,
    #[deser(rename = dc!("creator"))]
    creators: Vec<String>,
    #[deser(rename = atom!("updated"))]
    updated: DateTime<Utc>,
}

// entries we understand, and everything else is kept as it is
#[derive(Debug, Deserialize)]
#[deser(untagged)]
enum Item {
    Entry(Entry),
    Other(Value),
}

let item: Item = DeserializerConfig::new()
    .resolve_namespaces(true)
    .from_str(r#"
        <entry xmlns="http://www.w3.org/2005/Atom"
               xmlns:d="http://purl.org/dc/elements/1.1/">
          <title>Deser</title>
          <d:creator>John</d:creator>
          <updated>2026-09-29T21:00:00Z</updated>
          <d:creator>Jane</d:creator>
        </entry>
    "#)?;

XML uses namespaces which means that names need to be matched by their namespace, not by the prefix the document happens to use. Here the document says d: and the type says dc!. atom!("title") is just the string {http://www.w3.org/2005/Atom}title, which works because attributes are expressions. The two creators are collected into one Vec even though there is another element between them, and the text of updated goes straight into a chrono datetime. Because the enum is untagged, the entry has to be buffered before a variant is picked, and deser’s buffer keeps both creators. So the result is an Entry with John and Jane.

quick-xml, the most popular XML crate for Serde, drops the prefixes and ignores namespaces entirely, so a <x:title> from some other namespace is happily accepted as the title of the entry. The split list part though is considerably worse. A plain Entry fails with a duplicate field error for creator, unless you turn on the overlapped-lists feature (which, remember, is a global additive flag that any crate could set). That feature makes quick-xml read ahead to the end of the element and buffer everything in between, without a limit unless you set one.

But the feature only helps when quick-xml is hooked up to the struct directly and no buffering is taking place. Wrap the struct in the untagged enum and Serde buffers the entry itself. Read from that buffer, Entry sees creator twice and fails again. The fallback is a map, which keeps only the last creator, and there is no error. With or without the feature you get this:

Other({"creator": {"$text": "Jane"}, "title": {"$text": "Deser"}, ...})

Notice how John is gone.

Format specific extension types such as TOML datetimes are another case. TOML has them natively, Serde’s data model does not, so the toml crate passes them on as a map with a magic key. In Deser a datetime is an extension value, which formats that know it keep and all others write as a string:

let value: Value = deser_toml::from_str("released = 2026-09-29T21:00:00+02:00")?;

deser_json::to_string(&value)?;
// {"released":"2026-09-29T21:00:00+02:00"}
deser_toml::to_string(&value)?;
// released = 2026-09-29T21:00:00+02:00

The same with serde_json::Value gives you {"released":{"$__toml_private_datetime":"2026-09-29T21:00:00+02:00"}}, and reading the value into a chrono::DateTime fails outright with invalid type: map, expected an RFC 3339 formatted date and time string.

The Cost

So now that you know Deser is at least in theory cool, at what cost?

It is not free. The design relies on dynamic dispatch and on sinks and emitters that live on the heap, and that has considerable runtime overhead. In my own measurements for JSON, Deser reads somewhere between 33% faster and 60% slower than serde_json depending on the data. On average it’s about 10% slower for reading. Writes are between three times as fast and 70% slower and a wash on average. For YAML and TOML it’s noticeably faster than the Serde based crates, but that is more about the format implementations than the architecture.

Compile times slightly are better, but not dramatically so. Because it doesn’t monomorphize everything, release builds of derived code are about 2.3 times as fast as with Serde and that get a tiny bit better in practice for your own code as less recompilation is necessary.

To make Deser’s design work at all, it also uses unsafe internally. Most of this is to keep the chain of borrowed sinks on the heap. I feel like this is fine in the days of Miri and agents, but I know it makes some folks uneasy.

And well, the biggest cost is that it’s just not Serde.

How Much Is There?

Quite a lot actually which might be surprising. In addition to the core there is support for derive.

It supports all flavorts of JSON you can think of: JSON, JSONC, JSON5 and HJSON. (Fun fact here: they are all generated out of one shared parser template) For binary handling it supports CBOR and MessagePack. Additionally it does YAML 1.1 and 1.2, TOML, XML and all three flavors of Apple’s plist as well as CSV/TSV, urlencoded data and environment variables. For more crazy contraptions you can attach path info or capture location data as well as support for debug printing. You can perform validation as you parse, opt into different binary encodings in addition to base64, you can bridge to serde or capture dynamic values, transcode between formats or hook it up with tokio.

For documentation see docs.rs/deser and the code itself is on GitHub alongside many examples.

September 29, 2026 12:00 AM UTC