Topics covered in this episode:
* Free-threaded Python no longer “experimental” as of Python 3.14*
typed-ffmpeg
pyleak
* Optimizing Test Execution: Running live_server Tests Last with pytest*
Extras
Joke
Watch on YouTube
About the show
Sponsored by PropelAuth: pythonbytes.fm/propelauth66
Connect with the hosts
Michael: @
[email protected] / @mkennedy.codes (bsky)
Brian: @
[email protected] / @brianokken.bsky.social
Show: @
[email protected] / @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.
Brian #1: Free-threaded Python no longer “experimental” as of Python 3.14
“PEP 779 ("Criteria for supported status for free-threaded Python") has been accepted, which means free-threaded Python is now a supported build!” - Hugo van Kemenade
PEP 779 – Criteria for supported status for free-threaded Python
As noted in the discussion of PEP 779, “The Steering Council (SC) approves PEP 779, with the effect of removing the “experimental” tag from the free-threaded build of Python 3.14.”
We are in Phase II then.
“We are confident that the project is on the right path, and we appreciate the continued dedication from everyone working to make free-threading ready for broader adoption across the Python community.”
“Keep in mind that any decision to transition to Phase III, with free-threading as the default or sole build of Python is still undecided, and dependent on many factors both within CPython itself and the community. We leave that decision for the future.”
How long will all this take? According to Thomas Wouters, a few years, at least: “In other words: it'll be a few years at least. It can't happen before 3.16 (because we won't have Stable ABI support until 15) and may well take longer.”
Michael #2: typed-ffmpeg
typed-ffmpeg offers a modern, Pythonic interface to FFmpeg, providing extensive support for complex filters with detailed typing and documentation.
Inspired by ffmpeg-python, this package enhances functionality by addressing common limitations, such as lack of IDE integration and comprehensive typing, while also introducing new features like JSON serialization of filter graphs and automatic FFmpeg validation.
Features :
Zero Dependencies: Built purely with the Python standard library, ensuring maximum compatibility and security.
User-Friendly: Simplifies the construction of filter graphs with an intuitive Pythonic interface.
Comprehensive FFmpeg Filter Support: Out-of-the-box support for most FFmpeg filters, with IDE auto-completion.
Integrated Documentation: In-line docstrings provide immediate reference for filter usage, reducing the need to consult external documentation.
Robust Typing: Offers static and dynamic type checking, enhancing code reliability and development experience.
Filter Graph Serialization: Enables saving and reloading of filter graphs in JSON format for ease of use and repeatability.
Graph Visualization: Leverages graphviz for visual representation, aiding in understanding and debugging.
Validation and Auto-correction: Assists in identifying and fixing errors within filter graphs.
Input and Output Options Support: Provide a more comprehensive interface for input and output options, including support for additional codecs and formats.
Partial Evaluation: Enhance the flexibility of filter graphs by enabling partial evaluation, allowing for modular construction and reuse.
Media File Analysis: Built-in support for analyzing media files using FFmpeg's ffprobe utility, providing detailed metadata extraction with both dictionary and dataclass interfaces.
Michael #3: pyleak
Detect leaked asyncio tasks, threads, and event loop blocking with stack trace in Python. Inspired by goleak.
Use as context managers or function dectorators
When using no_task_leaks, you get detailed stack trace information showing exactly where leaked tasks are executing and where they were created.
Even has great examples and a pytest plugin.
Brian #4: Optimizing Test Execution: Running live_server Tests Last with pytest
Tim Kamanin
“When working with Django applications, it's common to have a mix of fast unit tests and slower end-to-end (E2E) tests that use pytest's live_server fixture and browser automation tools like Playwright or Selenium. ”
Tim is running E2E tests last for
Faster feedback from quick tests
To not tie up resources early in the test suite.
He did this with
custom “e2e” marker
Implementing a
pytest_collection_modifyitems
hook function to look for tests using the
live_server
fixture, and for them
automatically add the e2e marker to those tests
move those tests to the end
The reason for the marker is to be able to
Just run e2e tests with -m e2e
Avoid running them sometimes with -m "not e2e"
Cool small writeup.
The technique works for any system that has some tests that are slower or resource bound based on a particular fixture or set of fixtures.
Extras
Brian:
Is Free-Threading Our Only Option? - Interesting discussion started by Eric Snow and recommended by John Hagen
Free-threaded Python on GitHub Actions - How to add FT tests to your projects, by Hugo van Kemenade
Michael:
New course! LLM Building Blocks in Python
Talk Python Deep Dives Complete: 600K Words of Talk Python Insights
.folders on Linux
Write up on XDG for Python devs.
They keep pulling me back - ChatGPT Pro with o3-pro
Python Bytes is the #1 Python news podcast and #17 of all tech news podcasts.
Python 3.13.4, 3.12.11, 3.11.13, 3.10.18 and 3.9.23 are now available
Python 3.13.5 is now available!
Joke: Naming is hard