Topics covered in this episode:

Cyclopts: A CLI library
* The future of Python web services looks GIL-free*
* Free-threaded GC*
* Polite lazy imports for Python package maintainers*
Extras
Joke

Watch on YouTube

About the show

Sponsored by us! Support our work through:

Connect with the hosts

Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky)
Brian: @brianokken@fosstodon.org / @brianokken.bsky.social
Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky)

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am 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 our friends of the show list, we'll never share it.

Michael #1: Cyclopts: A CLI library

A CLI library that fixes 13 annoying issues in Typer
Much of Cyclopts was inspired by the excellent Typer library.
Despite its popularity, Typer has some traits that I (and others) find less than ideal. Part of this stems from Typer's age, with its first release in late 2019, soon after Python 3.8's release. Because of this, most of its API was initially designed around assigning proxy default values to function parameters. This made the decorated command functions difficult to use outside of Typer. With the introduction of <code>Annotated</code> in python3.9, type-hints were able to be directly annotated, allowing for the removal of these proxy defaults.
The 13:

Brian #2: The future of Python web services looks GIL-free

Giovanni Barillari
“Python 3.14 was released at the beginning of the month. This release was particularly interesting to me because of the improvements on the "free-threaded" variant of the interpreter.

Specifically, the two major changes when compared to the free-threaded variant of Python 3.13 are:
- Free-threaded support now reached phase II, meaning it's no longer considered experimental
- The implementation is now completed, meaning that the workarounds introduced in Python 3.13 to make code sound without the GIL are now gone, and the free-threaded implementation now uses the adaptive interpreter as the GIL enabled variant. These facts, plus additional optimizations make the performance penalty now way better, moving from a 35% penalty to a 5-10% difference.”
Lots of benchmark data, both ASGI and WSGI
Lots of great thoughts in the “Final Thoughts” section, including
- “On asynchronous protocols like ASGI, despite the fact the concurrency model doesn't change that much – we shift from one event loop per process, to one event loop per thread – just the fact we no longer need to scale memory allocations just to use more CPU is a massive improvement. ”
- “… for everybody out there coding a web application in Python: simplifying the concurrency paradigms and the deployment process of such applications is a good thing.”
- “… to me the future of Python web services looks GIL-free.”

Michael #3: Free-threaded GC

The free-threaded build of Python uses a different garbage collector implementation than the default GIL-enabled build.
The Default GC: In the standard CPython build, every object that supports garbage collection (like lists or dictionaries) is part of a per-interpreter, doubly-linked list. The list pointers are contained in a PyGC_Head structure.
The Free-Threaded GC: Takes a different approach. It scraps the PyGC_Head structure and the linked list entirely. Instead, it allocates these objects from a special memory heap managed by the "mimalloc" library. This allows the GC to find and iterate over all collectible objects using mimalloc's data structures, without needing to link them together manually.
The free-threaded GC does NOT support "generations”
By marking all objects reachable from these known roots, we can identify a large set of objects that are definitely alive and exclude them from the more expensive cycle-finding part of the GC process.
Overall speedup of the free-threaded GC collection is between 2 and 12 times faster than the 3.13 version.

Brian #4: Polite lazy imports for Python package maintainers

Will McGugan commented on a LI post by Bob Belderbos regarding lazy importing
“I'm excited about this PEP.

I wrote a lazy loading mechanism for Textual's widgets. Without it, the entire widget library would be imported even if you needed just one widget. Having this as a core language feature would make me very happy.”

https://github.com/Textualize/textual/blob/main/src/textual/widgets/__init__.py
Well, I was excited about Will’s example for how to, essentially, allow users of your package to import only the part they need, when they need it.
So I wrote up my thoughts and an explainer for how this works.
Special thanks to Trey Hunner’s Every dunder method in Python, which I referenced to understand the difference between __getattr__() and __getattribute__().

Extras

Brian:

Started writing a book on Test Driven Development.
- Should have an announcement in a week or so.
- I want to give folks access while I’m writing it, so I’ll be opening it up for early access as soon as I have 2-3 chapters ready to review. Sign up for the pythontest newsletter if you’d like to be informed right away when it’s ready. Or stay tuned here.

Michael:

New course!!! Agentic AI Programming for Python
I’ll be on Vanishing Gradients as a guest talking book + ai for data scientists
OpenAI launches ChatGPT Atlas
https://github.com/jamesabel/ismain by James Abel
Pets in PyCharm

Joke: You're absolutely right

Gaza-Verhandlungen - Wie fragil ist die Waffenruhe?

Der Tag

Warum bleibt Europa abhängig von russischem Gas?

The AI-powered Podcast Player