Sick Gaming - Python

[Py Blog] Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out

Sun, 25 Oct 2026 22:00:00 -0200

Here are expedited security releases of Python 3.15, 3.14, 3.13, 3.12 and 3.11.

They address the compromised eMudhra intermediate CA keys.
These keys are now blocked by the

Code:
ssl

module as a last resort against their use.
Normal uses of

Code:
pip

, including to upgrade

Code:
pip

itself, are now safe from attacks based on those compromised keys, even if

Code:
pip

hasn’t been updated yet.

Python 3.15.2 and 3.14.10 come with binary installers.
Python 3.13.18, 3.12.16 and 3.11.18 are source-only security releases.

Security content in all five releases

CVE-2026-115557 — gh-160040: Distrust compromised eMudhra intermediate CA keys
CVE-2026-114583 — gh-160097: Reject links replacing the destination in
Code:
tarfile.tar_filter
gh-160300: Reject cookies with a negative version in
Code:
http.cookiejar

Additional security content by version

Python 3.13.18, 3.12.16 and 3.11.18

These fixes were already included in Python 3.15.1 and 3.14.9.

CVE-2026-77214 and CVE-2026-102633 — gh-158876: Update bundled Expat to 2.9.0
CVE-2024-3220 — gh-159428: Don’t read
Code:
mimetypes.knownfiles
by default on Windows
gh-87720: Fix additional header refolding-quoting edge case

Python 3.13.18 and 3.12.16

This fix was already included in Python 3.15.0 and 3.14.9.

gh-157579: Fix race condition in the cleanup of
Code:
tempfile.TemporaryDirectory

For the full details, see the 3.15.2 changelog, 3.14.10 changelog, 3.13.18 changelog, 3.12.16 changelog and 3.11.18 changelog.

Stay safe and upgrade!

As always, upgrading is highly recommended to all users of affected versions.

Enjoy the new releases

Thanks to all of the many volunteers who help make Python development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation.

Your certified release team,

Hugo van Kemenade

Thomas Wouters

Pablo Galindo Salgado

Ned Deily

Steve Dower

[Py Blog] Python 3.15.1, 3.14.9 and 3.13.17 are out

Tue, 20 Oct 2026 22:00:00 -0200

Here are expedited security releases of Python 3.15 and 3.14, and a special security release of 3.13.

They all upgrade the bundled pip to version 26.2.2,
which includes certifi 2026.10.19 to address the eMudhra / emSign CA certificate security incident.

We don’t normally update pip for security releases like Python 3.13 because of backward compatibility concerns, but since 3.13 only just entered security-only mode, doing a special release with installers seemed prudent.

See the Discourse announcement for more information.

For all existing virtual environments on your system, please upgrade pip and uv to the latest versions.

To upgrade pip securely within a virtualenv:

Code:
python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

If you cannot immediately upgrade to this release, you can upgrade certificates for a Python 3.15 macOS installation and pip itself via:

Code:
/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install --upgrade certifi
/Library/Frameworks/PythonT.framework/Versions/3.15/bin/python3.15t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

For 3.14:

Code:
/Library/Frameworks/Python.framework/Versions/3.14/bin/python3.14 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
/Library/Frameworks/Python.framework/Versions/3.14/bin/python3.14 -m pip install --upgrade certifi
/Library/Frameworks/PythonT.framework/Versions/3.14/bin/python3.14t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

For 3.13:

Code:
/Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
/Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13 -m pip install --upgrade certifi
/Library/Frameworks/PythonT.framework/Versions/3.13/bin/python3.13t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

macOS 27.0

Code:
IDLE

and

Code:
tkinter

Additionally, the macOS installer for this release is built with a pre-release of Tk, fixing a possible hang on macOS 27.0 in applications using

Code:
tkinter

, like

Code:
IDLE

, in older releases.

Enjoy the new release

Thanks to all of the many volunteers who help make Python development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation.

Your certified release team,

Hugo van Kemenade

Thomas Wouters

Ned Deily

Steve Dower

[Py Blog] Python 3.16.0 alpha 1 is now available

Mon, 12 Oct 2026 22:00:00 -0200

This is an early developer preview of Python 3.16

python.org/downloads/release/python-3160a1/

What’s new in Python 3.16?

There’s plenty still to come in Python 3.16, but its first alpha is ready to try! Python 3.16.0a1 is the first of seven planned alpha releases.

During the alpha phase, features may be added up until the start of the beta phase (May 4, 2027) and, if necessary, may be modified or deleted up until the release candidate phase (July 27, 2027). The final release is planned for October 5, 2027. Please keep in mind that this is a preview release and its use is not recommended for production environments.

See What’s new in Python 3.16 for changes so far.

(Hey, fellow core team member, if there’s a feature you’d like highlighted in a future announcement, let Savannah know.)

If you maintain a library or application, please try it with this alpha and let us know how it goes. Please report Python bugs on the CPython issue tracker.

The next alpha, Python 3.16.0a2, is scheduled for November 10, 2026. The full schedule is in PEP 826.

More resources

And now for something completely different

For Python 3.16, this section will host the Python 3.16 Film Festival: one film pairing for each release, from the first alpha to the final version.

Building CPython is a team sport. Every release reflects the time, skill, and dedication of a community that cares deeply about Python and the people who use it. In that spirit, the festival will celebrate collaboration and craftsmanship: the care people put into their work, and what they can make together.

The Python 3.16 Film Festival opens with Ratatouille (2007). Remy’s passion for cooking and his partnership with Linguini make it a fitting place to begin.

Quote:Great cooking is not for the faint of heart. You must be imaginative. Strong-hearted. You must try things that may not work. And you must not let anyone define your limits because of where you come from. Your only limit is your soul. What I say is true: anyone can cook, but only the fearless can be great.

— Auguste Gusteau, Ratatouille (2007)

Enjoy the new release

Thank you to everyone who has contributed code, reviewed changes, written documentation, tested builds, and reported bugs. All of that work helps make Python and its releases possible. Please consider supporting Python by volunteering your time or encouraging your organisation to support the Python Software Foundation.

Happy testing!

Regards from beautiful Washington state,

Your release team,

Savannah Ostrowski

Ned Deily

Steve Dower

Julien Palard

[Py Blog] Python 3.15.0 (final) is here!

Thu, 08 Oct 2026 22:00:00 -0200

Python 3.15.0 is now available

python.org/downloads/release/python-3150/

This is the stable release of Python 3.15.0

Python 3.15.0 is the newest major release of the Python programming language,
and it contains many new features and optimisations compared to Python 3.14,
in 5,643 commits from 1,012 contributors.

Major new features of the 3.15 series, compared to 3.14

Some of the major new features and changes in Python 3.15 are:

Interpreter improvements

PEP 661: Add
Code:
sentinel
built-in type
PEP 686: Python now uses UTF-8 as the default encoding
PEP 798: Unpacking in comprehensions
PEP 810: Explicit lazy imports for faster startup times
PEP 814: Add
Code:
frozendict
built-in type
PEP 829: Package startup configuration files
The experimental JIT compiler has been significantly upgraded, with 7-8% geometric mean performance improvement on x86-64 Linux over the standard interpreter, and 11-12% speedup on AArch64 macOS over the tail-calling interpreter
Improved error messages

Significant improvements in the standard library

PEP 799: A dedicated profiling package for organizing Python profiling tools
PEP 799: Tachyon: High frequency statistical sampling profiler
More color

New typing features

PEP 728:
Code:
TypedDict
with typed extra items
PEP 747: Annotating type forms with
Code:
TypeForm
PEP 800: Disjoint bases in the type system

C API improvements

PEP 782: A new
Code:
PyBytesWriter
C API to create a Python bytes object
PEP 788: Protection against finalization in the C API
PEP 803, 820, 793: Stable ABI for free-threaded builds and related C API

Build changes

PEP 831: Frame pointers are enabled by default for improved system-level observability

Release changes

The official Windows 64-bit binaries now use the tail-calling interpreter
The official macOS binaries now install free-threading support by default

For more details on the changes to Python 3.15, see What’s new in Python 3.15.

Attention macOS 27.0

Code:
IDLE

Code:
tkinter

users

When running IDLE or other GUI applications that use the

Code:
tkinter

module, these applications may hang when using an application’s menu command that opens a dialog (for example, IDLE’s

Code:
About IDLE

Code:
Settings

, and

Code:
Open Module

commands) resulting in a spinning beach ball with

Code:
Force Quit

needed.

This problem is due to an operating system behavior change in macOS 27.0 that is believed to affect all current versions of the Tk graphics toolkit and thus the

Code:
tkinter

module in all current Python versions.

If you depend on Tk-based applications (like IDLE) on macOS, you may want to consider deferring installing macOS 27.0 until a Tk or macOS workaround is available or testing that your application workflow is not affected. Follow issue #158053 for updates.

More resources

Online documentation
PEP 790, 3.15 release schedule
Report bugs at github.com/python/cpython/issues
Help fund Python directly (or via GitHub Sponsors) and support the Python community

And now for something completely different

To celebrate the new 3.15, Barry Warsaw has a present for us!

Quote:I had this idea to whip up a little TUI adventure game that takes you through a What’s New in Python 3.15. I present to you “whatsnewt”:

From the README:

Quote:A TUI text adventure through what’s new in Python 3.15.

You wake up in the Startup Foyer, somewhere inside the interpreter, and work your way to the Release Gate. Along the way there are eighteen puzzles, and every one of them is a real 3.15 feature you have to actually use. You’re not just answering boring questions, you’re actually writing and running code, in a Python 3.15 interpreter.

Some puzzles require a type checker, and in those cases, answers are verified by pyrefly, which is a dependency for exactly that reason, and the verdict quotes what it says back.

The easiest way to play it is to run:

Code:
uvx --python 3.15 whatsnewt

And yes, there are easter eggs

Enjoy the new release

Thanks to all of the many volunteers who help make Python development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation.

Huge thanks to Georgi Ker and Marie Nordin for the Python 3.15 logo!

And also huge thanks to the Sovereign Tech Agency for supporting my work as release manager
for Python 3.14 and 3.15 through the Sovereign Tech Fellowship.

Salutations de Rennes,

Your release team,

Hugo van Kemenade

Ned Deily

Steve Dower

[Py Blog] Python 3.15.0 candidate 3 is here!

Thu, 01 Oct 2026 22:00:00 -0200

Following
recent
tradition,
here’s a surprise third release candidate for Python 3.15.0!

We got some last-minute lazy-import release blockers, and it makes sense to
include them in 3.15.0 final. It also makes sense to give a bit of time to test
them properly, so this week’s planned 3.15.0 final is postponed until next week,
and here’s an extra 3.15.0rc3.

python.org/downloads/release/python-3150rc3

This is a candidate preview of Python 3.15

This release, 3.15.0rc3, is the final planned release candidate, containing around 156 bugfixes, build improvements and documentation changes from 82 contributors since 3.15.0rc2. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release.

The next release of Python 3.15 will be 3.15.0 final, scheduled for 2026-10-09.

There will be no ABI changes from this point forward in the 3.15 series, and the goal is that there will be as few code changes as possible.

Call to action

We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.15 during this phase, and publish Python 3.15 wheels on PyPI to be ready for the final release of 3.15.0, and to help other projects do their own testing. Any binary wheels built against Python 3.15.0 release candidates will work with future versions of Python 3.15. As always, report any issues to the Python bug tracker.

Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is not recommended for production environments.

Core team: extra time to work on documentation

Are all your changes properly documented?
Are they mentioned in What’s New?
Did you notice other changes with insufficient documentation?

Major new features of the 3.15 series, compared to 3.14

Some of the major new features and changes in Python 3.15 are:

Interpreter improvements

PEP 810: Explicit lazy imports for faster startup times
PEP 814: Add
Code:
frozendict
built-in type
PEP 661: Add
Code:
sentinel
built-in type
PEP 798: Unpacking in comprehensions
PEP 686: Python now uses UTF-8 as the default encoding
PEP 829: Package startup configuration files
The experimental JIT compiler has been significantly upgraded, with 7-8% geometric mean performance improvement on x86-64 Linux over the standard interpreter, and 11-12% speedup on AArch64 macOS over the tail-calling interpreter
Improved error messages

Significant improvements in the standard library

PEP 799: Tachyon: High frequency statistical sampling profiler
PEP 799: A dedicated profiling package for organizing Python profiling tools
More color

New typing features

PEP 728:
Code:
TypedDict
with typed extra items
PEP 747: Annotating type forms with
Code:
TypeForm
PEP 800: Disjoint bases in the type system

C API improvements

PEP 803, 820, 793: Stable ABI for free-threaded builds and related C API
PEP 782: A new
Code:
PyBytesWriter
C API to create a Python bytes object
PEP 788: Protection against finalization in the C API

Build changes

PEP 831: Frame pointers are enabled by default for improved system-level observability

Release changes

The official Windows 64-bit binaries now use the tail-calling interpreter
The official macOS binaries now install free-threading support by default
(Hey, fellow core team member, if a feature you find important is missing from this list, let Hugo know.)

For more details on the changes to Python 3.15, see What’s new in Python 3.15.

Attention macOS 27.0

Code:
IDLE

Code:
tkinter

users

When running IDLE or other GUI applications that use the

Code:
tkinter

module, these
applications may hang when using an application’s menu command that opens a
dialog (for example, IDLE’s

Code:
About IDLE

Code:
Settings

, and

Code:
Open Module

commands)
resulting in a spinning beach ball with

Code:
Force Quit

needed.

This problem is due to an operating system behavior change in macOS 27.0 that is
believed to affect all current versions of the Tk graphics toolkit and thus the

Code:
tkinter

module in all current Python versions.

If you depend on Tk-based applications (like IDLE) on macOS, you may want to
consider deferring installing macOS 27.0 until a Tk or macOS workaround is
available or testing that your application workflow is not affected. Follow
issue #158053 for updates.

More resources

Online documentation
PEP 790, 3.15 release schedule
Report bugs at https://github.com/python/cpython/issues
Help fund Python directly (or via GitHub Sponsors) and support the Python community

And now for something completely different

Quote:At this moment the bow was in the hands of Eurymachus, who was warming
it by the fire, but even so he could not string it, and he was greatly
grieved. He heaved a deep sigh and said, “I grieve for myself and for
us all; I grieve that I shall have to forgo the marriage, but I do not
care nearly so much about this, for there are plenty of other women in
Ithaca and elsewhere; what I feel most is the fact of our being so
inferior to Ulysses in strength that we cannot string his bow. This
will disgrace us in the eyes of those who are yet unborn.”

[Py Blog] Python 3.10.22, 3.11.17, 3.12.15, 3.13.16 and 3.14.8 are now available!

Wed, 30 Sep 2026 22:00:00 -0200

A full sweep of Python releases is here: Python 3.10.22, 3.11.17, 3.12.15, 3.13.16 and 3.14.8 are now available! One last lap around the Sun for Python 3.10, and security updates across all five series.

Get them here:

Python 3.10.22 is the final release of Python 3.10. After five years, the series has reached end of life and will receive no further security updates. If you are still using Python 3.10, please plan your upgrade to a supported version.

Python 3.11 remains in security-fix-only mode until October 2027, as described in PEP 664. Security releases are made as needed, with no fixed cadence.

Python 3.10.22 and 3.11.17 are source-only. There are no Windows or macOS installers: 3.10.11 and 3.11.9 were the last releases in their respective series to include binary installers. These two releases contain security fixes rather than new features.

Python 3.12.15 is also a source-only security release, with security support continuing until October 2028. Python 3.13.16 is the last full maintenance release of 3.13; future 3.13 releases will contain security fixes only. Python 3.14.8 is a maintenance release, and both 3.13.16 and 3.14.8 include binary installers. See their release pages above for their full security content and other changes.

Discuss this release announcement.

Security content in all five releases

gh-158446: Fix crashes or incorrect output when formatting float or complex values with precision close to INT_MAX.
CVE-2026-19553 — gh-156793:
Code:
ssl.SSLContext.wrap_bio()
now validates its
Code:
server_side
,
Code:
server_hostname
, and
Code:
session
arguments.
Code:
asyncio
also validates TLS
Code:
server_hostname
arguments. On Python 3.10, 3.11, and 3.12, missing hostnames with
Code:
check_hostname
enabled emit
Code:
DeprecationWarning
for compatibility; they raise
Code:
ValueError
on Python 3.13 and later.
CVE-2026-82049 — gh-157190: Fix a tarfile extraction-filter vulnerability involving hard links to symbolic links that could expose files outside the destination and change their permissions or modification times.
gh-157953: Update bundled libexpat to version 2.8.5.
CVE-2026-15310 — gh-156002: Bound
Code:
zipfile
decompression per read for bzip2 and LZMA members, and for Zstandard members on Python 3.14, preventing unbounded allocations from small compressed members. Third-party decompressors supplied by monkey-patching
Code:
_get_decompressor()
that lack
Code:
needs_input
and two-argument
Code:
decompress()
remain vulnerable.
CVE-2026-19672 — gh-155999: Prevent tarfile extraction filters from creating directories outside the destination for paths that leave it and then return.
CVE-2026-19445 — gh-156293: Fix an ssl crash when an SNI callback switches contexts and the original callback context is no longer referenced.
CVE-2026-17084 — gh-155292: Restrict stringprep and the IDNA codec to Unicode codepoint attributes defined by RFC 3454.
CVE-2026-15806 — gh-155694: Scope urllib.request HTTPPasswordMgr credentials by URL scheme to prevent HTTPS credentials from being used for matching HTTP URLs.

Additional security content by version

Python 3.10.22, 3.11.17, 3.12.15 and 3.13.16

CVE-2026-87910 — gh-157265: Apply tarfile extraction filters when a link falls back to extracting an archive member, skipping members rejected by the filter.

Python 3.13.16 and 3.14.8

gh-158010: Update bundled OpenSSL to 3.5.9. In Python 3.13.16 this applies to Windows, macOS and Android, moving from OpenSSL 3.0.21 to the 3.5 LTS series. In Python 3.14.8 it applies to Windows, macOS, Android and iOS. The source-only Python 3.10–3.12 releases do not bundle OpenSSL.

Python 3.10.22

gh-149018: Improve protection against XML hash-flooding attacks in
Code:
xml.parsers.expat
and
Code:
xml.etree.ElementTree
when compiled with libexpat 2.8.0 or later.

This XML hash-flooding protection was already included in Python 3.11.16.

For the full details, see the 3.10.22 changelog, 3.11.17 changelog, 3.12.15 changelog, 3.13.16 changelog, and 3.14.8 changelog.

And now for something completely different

When two black holes merge, the newly formed black hole is distorted. It settles towards a stationary state by emitting gravitational waves in a process called ringdown. Like a struck bell, it oscillates with a signal that fades away. These oscillations are described by quasinormal modes; their frequencies and decay times depend on the final black hole’s mass and spin. You can watch spacetime doing its final ringing in this NASA simulation.

We started Python 3.10 with a trip inside a Schwarzschild black hole, so it seems only fair to finish with black holes as well :)

This is Python 3.10’s ringdown. One last release before we switch off the release machinery. Five years of features, fixes, stubborn buildbots, and a rather unreasonable number of tarballs. I cannot quite believe I am writing the last one.

Thank you to everyone who contributed patches, reviewed changes, tested releases, reported bugs, or helped us get a release out when the universe seemed determined to prevent it. It has been a privilege to be your release manager for this series.

Python 3.11 still has another year of security fixes ahead of it, so you have not escaped me yet :)

We hope you enjoy the new releases!

Thank you to all the volunteers who made these releases possible. Please consider supporting Python by contributing your time or through the Python Software Foundation.

Your friendly release team,

Hugo van Kemenade

Thomas Wouters

Pablo Galindo Salgado

[Py Blog] Python Language Summit 2026

Wed, 30 Sep 2026 10:00:11 -0200

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.

Photo by EuroPython (CC BY-NC-SA 4.0)

This marked the first time the Python Language
Summit had been hosted in Europe since 2011, 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
- “
  Code:
  AGENTS.md
  for CPython” by Gregory P. Smith and Łukasz Langa
- “Please read PEP 836 (JIT go brrr)” by Ken Jin

[Py Blog] Lightning Talks (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:10 -0200

One-time ABI breakage

By Mark Shannon

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Why break the Stable ABI? Because there are 32 spare bits in the
PyObject header that we currently can’t use.

Code:
[code]struct _object {
    Py_ssize_t ob_refcnt;  // Mark wants the high bits in this struct.
    PyTypeObject *ob_type;
};[/code]

Since PEP 683 was accepted in Python 3.12,

Code:
ob_refcnt

has effectively been treated as a 32-bit integer, but these
bits are still inaccessible for other uses to prevent breakages.
If the Python core team could repurpose these
bits, Mark could implement a better garbage collector and faster allocations.

Breaking the Stable ABI would be “easy to do… probably not painless though”,
in reference to users needing to port, recompile, and support multiple ABIs.

“Well… it’s going to happen anyway”, Mark said, referencing

Code:
abi3

and

Code:
abi3t

for
free-threading,
and how Python packages depending on the Stable ABI would need to move to the
new

Code:
abi3t

ABI.

Thomas Wouters provided an answer: wait until there is only a single Stable ABI,

Code:
abi3t

.
Free-threaded Python has not promised Stable ABI compatibility
for its object layout, unlike non-free-threaded Python, which exposed
details about

Code:
ob_refcnt

in the Stable ABI.

It was at this point that it began slowly dawning on Mark, to his horror, that free-threaded
Python may be solving his problem. After free-threading becomes the new Python default,
the Stable ABI that exposes the object header internals will be no more, and Mark
and team can make changes to the object header more freely. We’ll just have to be patient!

Safer and Generic Interruptions

By Daniele Parmeggiani

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Daniele presented a gap in implementing structured concurrency with threads in Python today:
the inability to safely interrupt tasks that failed or have been cancelled.

For example, let’s say there were two
I/O-bound parallel database queries sent as a result of a web request (task A and task B). If task A returned early with
an error, the result of task B would no longer be needed, because an exception would be raised anyway.
However, right now there is no way to cancel task B, so instead the result of task B is waited for
and then thrown away before propagating the exception from task A.

Interrupts are one way to implement this cancellation mechanism.
Daniele explained that the machinery to implement cancellations via interrupts is “already available in CPython,
but isn’t exposed at the Python level”. And why isn’t this functionality exposed? Because it’s a huge source of “footguns”.

Instead of exposing the unsafe functionality directly, Daniele would like to offer users
a way to handle interruptions safely. To do this, Daniele proposes adding uninterruptible scopes,
where a context manager’s

Code:
__enter__()

and

Code:
__exit__()

methods are
“shielded” from being interrupted and are guaranteed to execute.

“You can’t really rely on [context manager cleanups] with interruptions right now”.
If you read the documentation of the signal module,
it tells you to turn off signals because they aren’t safe. “It’s a bit weird that the documentation for signals says that”.

“Is this good for performance? No, it adds more bytecode”, Daniele said, closing his presentation, “but
I’ve made sure to make Mark Shannon happy”. Daniele invited anyone who is interested
in an implementation of this functionality to contact him.

EktuPy, Scratch but Python

By Kushal Das

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Kushal Das brought a short presentation on a project he’d been working on to teach Python to the generation of young programmers who learned using Scratch. Scratch is a programming language that is represented using blocks instead of text to create animations, games, and other media-focused programs.

EktuPy brings many of the features that are beloved in Scratch, such as the focus on media like games and animations, and the “remix” concept to give new programmers a working base to start with instead of a daunting blank canvas. EktuPy tries to bridge the gap between block-based programming languages and text-based languages like Python.

AGENTS.md for CPython

By Gregory P. Smith and Łukasz Langa

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

CPython, just like many other open source projects, has been seeing many contributions from folks using LLM agents. Gregory P. Smith and Łukasz Langa wanted to get a “vibe check” from core developers about adding a simple

Code:
AGENTS.md

file to the CPython repository. The hope was that even basic guidance about how to contribute to CPython (such as linking to the Developer Guide) would improve the quality of the large number of pull requests made using agents.

Greg asked for a show of hands for “who would be against adding an

Code:
AGENTS.md

to the repository”, and no core developer hands were raised. “Oh, that was easier than I thought”. Thomas Wouters remarked that he “wished it wasn’t necessary” to have an

Code:
AGENTS.md

.

Another issue raised was that

Code:
AGENTS.md

files tend to receive many outside contributions from people wanting to add new things. Greg made it clear that the file would be kept very simple and “seldom change”, suggesting that the core team would “reject pull requests that modify the file”.

Seth Larson asked about quantifying the improvement to contributions, citing that the Python Security Response Team had seen increased volumes of LLM-generated reports. Changes to the security policy and adding a threat model appeared to work, but this was difficult to prove.

Łukasz shared his pessimistic view that CPython would someday have to stop accepting many outside contributions due to the large number of agent-driven contributions.

Please read PEP 836 (JIT go brrr)

By Ken Jin

Closing out the Language Summit lightning talks, Ken Jin had a simple request: to please read PEP 836. Ken had only received 33 replies on the PEP discussion thread for PEP 836, and encouraged core developers (and anyone reading this blog post) to read the PEP and “tell us what you disagree with”.

[Py Blog] PEP 827: Type Manipulation (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:09 -0200

Michael J. Sullivan came to the Language Summit to discuss PEP 827, a PEP that includes many proposed improvements to Python type annotations. For the Python Language Summit, Michael wanted to focus in particular on one aspect: how type annotations are stored.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Michael began by introducing PEP 827 “by looking at a completely different programming language”. He brought up an example from Prisma, an object-relational mapper (ORM) library written in TypeScript. Calling

Code:
findMany

on a

Code:
User

model infers a return type based on the input parameters’ values, such as when selecting a subset of fields:

Code:
[code]const user = await prisma.user.findMany({
  select: {
    name: true,
    email: true,
    posts: true,
  },
});[/code]

This query derives a type that looks like this in TypeScript:

Code:
[code]{
  email: string;
  name: string | null;
  posts: {
    id: number;
    title: string;
    content: string | null;
    authorId: number | null;
  }[];
}[][/code]

With PEP 827, Python’s type annotations could work similarly. Return types
could be inferred from a function’s input parameter types.

Another use-case PEP 827 serves is generating new types programmatically, such as for CRUD (Create, Read, Update, Delete) web applications, where a single database table typically has a separate ORM model definition for each CRUD operation. Create would require all properties without defaults, Read would include all the public properties of a model, and Update would make all properties optional (supporting the

Code:
PATCH

HTTP method). Delete doesn’t typically need a model, as only the primary key is needed to delete a record.

The example given in PEP 827 uses a

Code:
Hero

model, which has a

Code:
secret_name

and an optional

Code:
age

parameter, and creates three other models for the “public get”, create, and update operations:

Code:
[code]class HeroBase(SQLModel):
    name: str = Field(index=True)
    age: int | None = Field(default=None, index=True)

class Hero(HeroBase, table=True):
    id: int | None = Field(default=None, primary_key=True)
    secret_name: str

class HeroPublic(HeroBase):
    id: int

class HeroCreate(HeroBase):
    secret_name: str

class HeroUpdate(HeroBase):
    name: str | None = None
    age: int | None = None
    secret_name: str | None = None[/code]

Keeping all of these models and parameters up-to-date with the database model requires lots of diligence and can’t usually be done programmatically. So what if there was a way to instead contain the complexity within a type that transforms the overall model type for each of the CRUD operations? PEP 827 would allow writing Python types like the example below, containing the complexity in the

Code:
Public

Code:
Create

, and

Code:
Update

annotations:

Code:
[code]class Hero(SQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)
    name: str = Field(index=True)
    age: int | None = Field(default=None, index=True)
    secret_name: str = Field(hidden=True)

type HeroPublic = Public[Hero]
type HeroCreate = Create[Hero]
type HeroUpdate = Update[Hero][/code]

Type manipulation primitives in PEP 827

The core of the idea is introducing a handful of primitives to Python’s type system:

Conditional types (
Code:
true_type if bool_type else false_type
).
Comprehension types (
Code:
*[t for t in Iter[iter_t]]
). Comprehension types can have conditional
Code:
if
clauses, just like regular comprehensions.
Member types (
Code:
typing.Members[t]
would return an iterable of the type’s members).
Code:
member.name
and
Code:
member.type
would be properties of the member.

The PEP was “inspired by TypeScript, but importantly [the PEP] is not modeled after TypeScript”. Michael noted that Python and JavaScript are “very different languages”, so the system ended up looking “quite a bit different”. The PEP was also designed so that no new keywords would be required to adopt it.

PEP 827 contains many other proposed features that Michael didn’t have time to cover, including new operators, callable special construction, tuple slicing and length, iterating over unions, getting types of an attribute, inspecting initializers, and ways to handle

Code:
__init_subclass__

decorators. The PEP contains a mypy-based prototype for all the features being proposed.

How to store type annotations?

Having introduced the PEP, Michael then returned to his original motivation: discussing how to store type annotations for runtime use. Popular libraries like Pydantic and FastAPI use type annotations at runtime to drive their behavior. “This was complicated by our desire to use Python-y syntax”, like

Code:
if

Code:
for

, and dot notation.
In concrete terms, Python will itself evaluate the types at runtime. In order to implement everything in PEP 827, there would need to be a way to access the unevaluated type even after Python had
executed the conditionals or iterations. As currently drafted, “the PEP is carefully designed to support an evaluator that works by calling the __annotate__() functions”.

There’s already a module,

Code:
annotationlib

, which has a “string format” (Format.STRING). In theory, if you call

Code:
annotationlib.get_annotations(..., format=Format.STRING)

, then you’d get the type annotation back unevaluated. “But this isn’t how this function is implemented today”; instead, the function does “dreadfully clever stuff” using proxy objects that overload every dunder method.

Imogen Hergeth has drafted PEP 849 proposing a new “AST” format that is related to this problem, but Michael thought it would be smaller and more straightforward to make the

Code:
STRING

format work with conditional expressions. “There’s a surprisingly large design space here with trade-offs between time, space, and complexity”.

One of the original ideas considered by the PEP that moved to

Code:
__annotate__()

functions was “can we just store the strings?” The most straightforward option would be for

Code:
__annotate__()

to support

Code:
STRING

in addition to

Code:
VALUE

and

Code:
VALUE_WITH_FAKE_GLOBALS

. The

Code:
__annotate__()

function would get a little bigger, but if

Code:
STRING

is passed as the format, it would return the strings “instead of requiring the library to do something complicated to get there”.

This approach is fast, but uses more memory by representing annotations redundantly. The team considered whether to do the “even more obvious thing” and evaluated storing only the strings. But this isn’t enough; type annotations can refer to local variables, so evaluating them requires more context. “This is the whole reason we moved away from

Code:
from __future__ import annotations

(PEP 563), did PEP 649, and added complexity to generating

Code:
__annotate__

functions”.

Michael detailed a proposed alternate approach that saves memory at the expense of computation speed: “If we have the string for a type annotation, and we have the environment closure for

Code:
__annotate__

, then we can

Code:
eval()

the string in that closure and it will work. What would that look like?
Generate an

Code:
__annotate__

function that only implements the format for

Code:
STRING

, but is set up to only contain the free variables that the annotation used. If the type annotation refers to local
variables, the annotation will still depend on [the variables], [the type annotation] wouldn’t directly do anything with [the variables]. [The type annotation] would just build the dictionary with the strings.
We’d have a function in

Code:
annotationlib

that knows
how to pull [the variables] out, combine that with the strings, and evaluate them [both] properly. We could make

Code:
__annotate__()

call that [annotationlib] function when you ask for an evaluated type annotation”.
This approach would use a lot less memory than using strings, but would be much slower because you’d need to use eval().

Discussion

Stefan Behnel asked whether accepting PEP 827 would make the type system Turing-complete with the proposed conditionals and comprehensions. Michael replied that the Python type system “is already Turing-complete, but only accidentally Turing-complete”. Java had run into this issue with generics with subtyping bounds, and “Python does the same Generic stuff as Java”. “There was never an intention for the type system to be Turing-complete”, therefore accepting PEP 827 would only change the type system to be “intentionally Turing-complete”.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Łukasz Langa commented on the aesthetics of the proposed syntax, pointing out the example of the comprehensions with “stars”. He cautioned core developers against seeing this syntax and having a knee-jerk negative reaction, such as thinking: “Oh [f-string], they’re going to make type hints look even worse”. Łukasz was clear that “…these features are for [frameworks] to implement internally [features] that allow type checkers to magically generate the correct types”. “Users are not meant to write types like these or only use them very rarely”.

Łukasz also commented on the performance of using strings: when he first wrote

Code:
from __future__ import annotations

, one of the motivations was that strings are “interned”. Using string interning for types would take “less memory”. The problem was that the alphabet for interning strings doesn’t allow for square brackets (

Code:
[]

), which are used often in Python type annotations. There was a question whether this could be changed in Python, to which Łukasz replied that “we could, but then we ruin Python for everybody else” because this behavior has been “relied on for over 30 years”. “However…”, Łukasz continued, “what if

Code:
__annotate__()

interned [strings] all the time?” We expect many type annotations to be the same or similar, like

Code:
None

Code:
str

, and

Code:
str | None

. Łukasz suggested that this method “wouldn’t cost much memory”, which Michael agreed with.

David Hewitt shared his experience working with TypeScript, where there are very complicated types. “When you’re a TypeScript user and you’re trying to figure out an API, you start clicking down through the API layers”, and you often hit the issue (“as Łukasz described”, with an accompanying “oh [f-string]”). David was concerned about whether this new syntax would be something that users would encounter frequently.

Michael confessed that users clicking into “the select method” on an ORM would “see a wild type” and “there’s no getting around that”. “…but hopefully they’ll see the docstring first. If they look at the return type they’ll see something nice”. “I think there are cases where you’re doing

Code:
select(User)

you might be able to populate specific properties”, but this would be “potentially finicky” and dependent on the language server being used.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

“There will be moments where users discover that the world is complex”, Yury Selivanov, a co-author of the PEP, said, acknowledging the need for complex type annotations. “Right now the world is not typed”. “The Python type system does not match the expressiveness of the language”. “Certainly some people might be confused”, he added, listing a few ways to mitigate this issue, such as better IDEs, language servers, and documentation.

[Py Blog] Free-Threaded Python Post-Era (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:08 -0200

Tobias Wrigstad and Fridtjof Stoldt returned to the Python Language Summit, now joined by Donghee Na. Tobias and Fridtjof previously presented “Fearless Concurrency” to the Python Language Summit in 2025. This year the topic at hand was the “post-era of free-threading Python”, and what high-level concurrency primitives would be provided by Python.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Comfortable doesn’t mean “Good”

Today the interface for accessing free-threading is, unsurprisingly, “threads”. Threads are how people typically first learn about true parallelism from school, textbooks, and other familiar materials. But what if threads as a user interface aren’t very good? Using threads means users need to care about deadlocks and race conditions.

Python’s free-threading project has made considerable progress since PEP 779’s acceptance. But there was one aspect of PEP 779’s acceptance criteria that hadn’t been addressed yet: high-level concurrency primitives. The Steering Council’s acceptance stated:

Quote:Preparation for high-level concurrency primitives.

The Python core team should begin considering and proposing higher-level concurrency primitives that users can use safely and effectively, without requiring a deep understanding of the underlying threading mechanism. And the SC wishes that this task should be prioritized once the above tasks are stable. We recommend using the
Code:
concurrent
package in the stdlib for this, where appropriate.

There is some prior art here; other programming languages provide primitives Python can be inspired by, such as Rust’s ownership and borrowing, Go with channels and goroutines, and Erlang with actors and sending messages.

Fast, Simple, or Safe: what should Python concurrency be?

The talk opened by contrasting approaches to implementing concurrency in different programming languages on three separate axes that are “sometimes at odds with each other”: speed, simplicity, and safety.

C is fast and simple, offering direct access to memory through pointers, which also allows dangerous and unsafe operations; C relies on programmer discipline for program correctness. Erlang has multiple threads, but to communicate, data is copied over to the other “actor”, so it’s safe and simple, but performance suffers. Rust is performant and safe, but it’s not simple: “you’ll find yourself often fighting with the borrow checker”.

“Where would we put Python on this triangle?”

Python using the Global Interpreter Lock (GIL) (represented as a single lock on the graphic) is a simple model, but it’s not completely safe, as the GIL “only protects the runtime”. Subinterpreters (represented as multiple locks on the graphic) as a model are safer due to the isolation, but this model isn’t simple or performant due to data copying. Finally, there is free-threaded Python (racecar in the graphic), which is very similar to C: simple and performant, but it puts the burden on programmers for program correctness and safety.

The three argued that for a high-level model “safety would be a priority and then performance”, with “simplicity as third”. “Simplicity is at odds with performance”.

Behavior-Oriented Concurrency (BOC)

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Behavior-Oriented Concurrency (BOC) is the model the trio is proposing for a high-level concurrency interface for Python. Programs written with the BOC model are task-based. Tasks are lightweight, can run on any core, and cannot deadlock.

Each task owns data that is protected by mutexes, but unlike the threading.Lock objects that we’re used to in Python, these mutexes are aware of the data that they protect. This data awareness means that the mutexes can ensure that the data objects are only accessed by a single task at a time, providing isolation and preventing data races. BOC calls these mutexes “Cowns”, meaning “concurrent owner”.

BOC allows defining which mutexes a task depends on using the

Code:
@when

decorator. One or more mutexes can be specified in this decorator, and tasks can only access data through mutexes that the task depends on. This mechanism is what allows BOC to create a dependency graph across all tasks and data.

Providing a scheduler with a program written with the above constraints gets you three important properties: no deadlocks, no data races, and good “locking discipline”. The user “wouldn’t need to decide to spawn a thread or subinterpreter”; this would be handled by the runtime. The scheduler would be able to turn detected deadlocks or data races into exceptions instead, detecting these situations ahead of execution.

Some examples of programs written using locks and threads were then transformed into programs using the BOC model, such as two bank accounts transferring money between them and printing the results:

Code:
[code]from bocpy import Cown, wait, when

class Account:
    def __init__(self, name: str, balance: float):
        """Initialize an account with a starting balance."""
        self.name = name
        self.balance = balance

    def __repr__(self) -> str:
        """Return a readable representation for debugging."""
        return f"Account(name='{self.name}', balance={self.balance})"

def atomic_transfer(src: Cown[Account], dst: Cown[Account], amount: float):
    """Move funds from ``src`` to ``dst`` if both are unfrozen and funded."""
    @when(src, dst)
    def do_transfer(src: Cown[Account], dst: Cown[Account], amount=amount):
        src_account = src.value
        dst_account = dst.value
        if src_account.balance > amount:
            src_account.balance -= amount
            dst_account.balance += amount

def check_balance(message: str, account: Cown[Account]):
    """Log the current balance of the provided account."""
    @when(account)
    def do_check(account: Cown[Account], message=message):
(message, account.value)

alice = Cown(Account("Alice", 100))
bob = Cown(Account("Bob", 0))

check_balance("src (before transfer):", alice)
check_balance("dst (before transfer):", bob)
atomic_transfer(alice, bob, 10)
wait()[/code]

There are many more examples available on GitHub. This proof of concept, implemented using subinterpreters, is available for anyone to try: bocpy, available on the Python Package Index:

Code:
[code]python -m pip install bocpy[/code]

Checking bocpy against their own criteria of simplicity, safety, and performance: bocpy is simple, as can be seen in the above examples. On the safety front, bocpy today runs in “stable Python”, and for this reason only isolation has been implemented so far. “We don’t yet have ownership, you can’t implement [ownership] as a third-party library”, as this would require changes to the runtime. Performance is “good for programs that aren’t communication dominated” due to “communication being expensive for subinterpreters”.

The bocpy package provides three features:

“Cowns”, or locks with ownership
Behaviors (the tasks spawned with
Code:
@when
decorators)
Scheduler (implemented with subinterpreters, with planned support for free-threading)

Looking forward, the three have two other proofs of concept that modify the Python runtime “to allow for safe concurrency and create safe abstractions while keeping performance”. The first implements isolation by organizing the heap into isolated groups of objects, where ownership violations would raise an exception from Cowns. The second is for immutability of Python objects (PEP 795).

The group made it clear that changes to core Python would be needed to support safe concurrency, asking whether Python would trade “some performance for safety”. What primitives do we want to provide in the standard library; are locks enough? And if we do provide primitives, should they be something like bocpy?

Discussion

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Thomas Wouters recalled that the core team “has experience trying to create universal interfaces for subprocesses, multiprocessing, threading”. In practice, there are always corner cases, and performance is suboptimal because of the constraints of the APIs. Thomas asked “how confident [the three] are that this isn’t the case for bocpy?” The three shared Thomas’s concern. “This is a question we’re working on”, answered Fridtjof. “If you have [the bocpy] ownership model it’s possible to treat subinterpreters and threads similarly, you can have communication, and you can share objects directly with the ownership model”.

“Notion of tasks and schedulers immediately brings async to my head”, David Hewitt said, wondering “how does async fit into this picture?” He asked the trio whether bocpy “should be built on asyncio” and have “async mutex primitives instead of being [synchronous]”. Tobias confirmed that bocpy “could be” built using

Code:
asyncio

: “it depends on what backend infrastructure” is used and the trade-offs of each backend. “If you want to do some I/O, you tell the I/O library to put something into a cown once data is available and schedule a task to run when the data is available to avoid blocking”.

Larry Hastings was “happy to see this research going on” and welcomed more from the group, but didn’t see bocpy or any singular solution as “the” method to do concurrency in Python. “[Larry] would like Python to have all the tools that give you and other groups with competing ideas the ability to implement ideas and provide them to users”. Instead, Larry was wary of “anointing a single way”, to avoid locking Python into a particular implementation in case better options are discovered later. Donghee shared that the group wasn’t initially trying to force a single way, only to start the conversation.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Fridtjof brought up Rust as an example of where not providing high-level primitives on top of

Code:
async

and

Code:
await

resulted in a “split” in the Rust ecosystem. “Sounds lively”, Larry responded.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

David Hewitt shared that a lot of the Rust community regards the “Rust async situation” as “slightly failed”, as the standard library lacked any standard interface for the runtime. As a result, the entire Rust ecosystem has been “forced” to converge on Tokio. David agreed with Thomas that it would be “tough to come up with a good abstraction”, but that this “doesn’t mean we shouldn’t try”.

[Py Blog] Developer-in-Residence Update & Future (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:07 -0200

The first three Python Developers-in-Residence are Łukasz Langa, Petr Viktorin, and Serhiy Storchaka. Now that Developer-in-Residence Łukasz is moving on from the role after five years, the now-“ironically named” Deputy Developer-in-Residence Petr came to the Language Summit to give an update on the role and ask core developers what’s next.

Petr started the discussion by listing the responsibilities in his contract:

Keeping the core development workflow operational to ensure core developers and collaborators are not blocked from contribution.
Improving tools and workflows, which are part of the core development experience, to enable a smoother contribution process.
Code review of a subset of incoming changes to CPython to help collaborators receive timely communications on their changes.
Authoring own changes to CPython to help clean the issue and PR backlog.
Responding to requests for assistance from core developers in a timely manner.
Regularly reporting on this work to the Steering Council and the wider community.
Additional responsibilities as directed.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Referencing the explicit “Responding to requests for assistance from core developers”, Petr noted that there “haven’t been that many requests for assistance” recently, so he wanted to ask core developers to communicate what they might want done, either at the Language Summit or later.

Petr continued with an update on what he’d accomplished from 2024 to 2026, including maintaining buildbots, mentoring multiple people into becoming triagers or core developers, working on the Stable ABI for free-threaded Python, working on security vulnerability fixes, and managing CPython sprints at conferences. He compared this work to what Łukasz had accomplished in his five years of tenure, which included more “large-scale project management”, organizing events like the Language Summit, talking to sponsors, and overseeing the other Python Developers-in-Residence.

Petr summarized his approach to the role as focusing on “important tasks, but leaving fun and glamorous ones to volunteers”. He also noted collaborating with people in other “Developer-in-Residence”-like roles, such as Hugo van Kemenade and Stan Ulbrych, who are Sovereign Tech Agency fellows focusing on CPython. Petr opened the floor for discussion by asking what challenges core developers would like the Developers-in-Residence to focus on.

Discussion

Photo by EuroPython (CC BY-NC-SA 4.0)

“Thank you for doing all the boring stuff”, Ken Jin opened, appreciating Petr taking on grunt work that enables other core developers, and sharing that if he had to do this work as a volunteer he “would have quit a long time ago”.

“You don’t have to do everything Łukasz did”, Thomas Wouters assured Petr, “we’re hiring a replacement for Łukasz and will sort out what that means for the team”, reminding everyone that the Steering Council members are all volunteers themselves, that managing multiple full-time employees is difficult, and that hiring takes time.

Former Developer-in-Residence Łukasz Langa chimed in with a problem he and other core developers had noticed: the large volume of (likely) LLM-generated pull requests being submitted to CPython. One of Łukasz’s early goals for CPython when he joined as Developer-in-Residence was “addressing the PR backlog”, which was successful for some time, but that progress has now completely reversed with LLMs. Łukasz suggested either triaging these PRs somehow, noting he wasn’t sure “how many full-time jobs that task is”, or coming up with “some systematic solution”.
Petr confirmed triaging every LLM pull request wasn’t something he wanted to do, but he was “hired to also do tasks he didn’t want to do”.

There was some discussion between Stefan Behnel and Mark Shannon about ensuring some amount of review “before a human looks at a pull request”, such as having an LLM provide a first pass on a pull request.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Savannah Ostrowski was hesitant to engage with drive-by LLM contributions: “I’m not willing to give away my time because it won’t change their behavior”. She suggested that other core developers “nope out” if they didn’t want to engage.

Mark Shannon recommended everyone .
There is also a Language Summit Lightning Talk by Gregory P. Smith and Łukasz Langa about attempting to
steer or improve these contributions using

Code:
AGENTS.md

[Py Blog] Spicycrab (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:06 -0200

Kushal Das brought a project that fills a niche for Python users who hit a performance wall that can’t be solved by scaling horizontally, but who also don’t want to learn a new programming language. Spicycrab is a Python-to-Rust transpiler named for Kushal’s love of spicy food. The demonstration showed compiling a simple Python script to Rust source code and then into an executable binary.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Code:
[code]crabpy transpile greet.py -o greet[/code]

This simple demo produces Rust source code at

Code:
greet/src/main.rs

, which can be run with

Code:
cargo run

.

Who is this for?

After introducing the tool, Kushal shared more about who could benefit from a tool like Spicycrab.

Back when Kushal was working with Django, there would often be a moment where the web service could no longer scale on the single virtual machine that was allocated to the team. At that time in 2008, the only option was to learn to write C extensions for the “hot paths”, but this approach meant you weren’t writing Python and you had to contend with crashes and security issues from writing C.

Now that Rust is here, some of the challenges like security and crashing are addressed, but Rust’s “syntax breaks [his] brain” (although PyO3 helps). Kushal wanted to get more people taking advantage of Rust’s performance without needing to learn Rust.

Kushal shared that many smaller organizations he knows in this exact resource-constrained situation would move away from a programming language like Python towards a language like Go for web backends. Kushal wanted to provide a tool that offers easy performance without needing to leave Python behind. “I hope that Python can become that fast one day, but what can we do until then?”

Next, Kushal demonstrated an async web service using actix-web, which includes type annotations. This mechanism works by transpiling Python code written using actix-web patterns into idiomatic Rust, with the actix-web API made available to Python beforehand as a package of generated stubs.

Kushal installed actix-web using Cargo, with a few chuckles as 180 dependencies were downloaded and compiled, a callback to some concerns from the “Rust for CPython” project regarding third-party dependencies. After installation and transpiling completed, the following web server was built using Spicycrab:

Code:
[code]from spicycrab_actix_web import App, HttpServer, HttpResponse, get

async def hello() -> HttpResponse:
    return HttpResponse.Ok().body("Hello World!")

async def main() -> None:
    HttpServer.new(App.new().route("/", get().to(hello))).bind("127.0.0.1:8080").run()[/code]

After running the transpiler and compiling again, the resulting binary served the “Hello World!” response over HTTP.

Discussion

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Ken Jin asked why this approach would be chosen over mypyc, Cython, or SPy. Kushal answered that
“SPy only supports a subset of Python” but admitted that “mypyc is good and in many cases that [mypyc] could be used directly”. Kushal’s primary
motivation for going this route was to solve multiple problems at once, and one of the problems was getting
Python users to use Rust “without being scared of the syntax”.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Gregory P. Smith provided a “spicier” thought that was “existential for Python”. Greg imagined it becoming more commonplace for state-of-the-art large language models to rewrite code from one programming language to another, such as from Python to Rust for performance. Kushal noted that this solves the issue “one time”, but doesn’t answer how the code is maintained long-term, and that the cost of doing so would be prohibitive for many. As an example, the rewrite of Bun from Zig to Rust cost $165,000 USD.

[Py Blog] Rust for CPython (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:05 -0200

“No one said ‘don’t do this’ last year”. After testing the waters at PyCon US 2025, David Hewitt returned to the Python Language Summit asking what Python core developers want from Rust, along with proposed timelines, phases, and success criteria for how the Rust for CPython project might proceed and become a permanent fixture within the CPython project.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

David is acting as an “ambassador” for the Rust for CPython project team, which is currently led by core developers Kirill Podoprigora and Emma Smith as authors of the Rust for CPython PEP draft. Emma also about the Rust for CPython project. The team itself is around 60 developers in a Discord channel, among them a “few [Python] core developers” and a “delegation from the Rust project”. The team has experience with previous projects integrating Rust into existing codebases, such as Android and the Linux kernel, and is “excited by the work and keen to support [the project] if we proceed”.

Why Rust?

Showing how adopting Rust may specifically help CPython, David noted how the number of issues labeled with “

Code:
type-crash

” has been steadily rising over time. “We’ve been making some big technical bets”, he said, referencing the new parser, the JIT, and free-threading. These large, complex features may be one of the reasons more crash reports are being opened on GitHub, and Rust could be a potential solution here. David explained that Jeff Vander Stoep described Rust in Android as “move fast and fix things”, and that “fewer revisions for patches of the same size” was the experience Android has had since adopting Rust.

Rust and Python are already working together in Python’s ecosystem of packages thanks to PyO3 and Maturin. David also emphasized that many technology companies were “choosing Rust as a bet” instead of only as the new shiny tool.

But adopting Rust into CPython would not all be smooth sailing; there were still concerns that David and the team are aware of.

One of the biggest concerns from a year ago was Rust’s lack of platform support compared to CPython, which at the time of writing officially supports 20 different architectures and platforms at either Tier 1, 2, or 3. David shared that Rust’s support of different platforms has “widened since last year” and was becoming “less and less of a concern”. The proposal would be to ask Python distributors to attempt using the optional Rust support in Python 3.16 (October 2027) and report platform-specific issues upstream in time to be resolved around the Python 3.17 timeline (October 2028).

David acknowledged that adopting Rust into a project is a social challenge as much as a technical challenge. Rust knowledge is “not universal amongst core developers”, which would be partially mitigated by “targeting small portions” of CPython and an incremental approach, as “1 million lines of C code can’t be ported all at once”.

David was clear that using Rust in itself does not necessarily mean that ported code would be free of bugs or security issues. Although Rust does mitigate classes of issues that commonly create bugs, the code can still have correctness issues. The team proposes mitigating this by adopting property-based testing, fuzzing, and using “prudent engineering practices” during the porting process.

The proposed first Rust module: zlib

Below are the proposed timelines for the Rust for CPython project making a “significant improvement” to CPython, with a PEP defining the success criteria for Rust expected in late 2026. Under this timeline, the first Rust code to ship in Python would be in Python 3.16, where it would be completely optional, with the existing C code kept as a fallback. The earliest that Rust would become required to build CPython is Python 3.18 in 2029, at least three years away.

The timeline includes a build system and CI, Rust API proof-of-concept happening
in the Summer 2026, a PEP defining success criteria in late 2026,
an optional Rust backend for the zlib module and private Rust API in Python 3.16 (October 2027),
resolving platform issues and Rust in more places (io, json, xml, memoryview, parser)
for Python 3.17 (October 2028). Finally, in some distant Python version (October 2029+)
the Rust build would be made required and a public Rust API would be published.

The Rust for CPython team has selected the zlib module as the first module to be given an optional Rust implementation because they “wanted to achieve a significant improvement” with a “small scope”. The proposed Rust implementation will use zlib-rs, which is “heavily tested and used by the Firefox, uv, and Cargo” projects and “faster than zlib and zlib-ng on many platforms”. The module was also selected because it’d require using an external Cargo package, meaning this aspect of the build process would need to be designed and exercised.

This small change would have an impact: the zlib compression algorithm is “widely used by Python packaging”, meaning that (almost) “every

Code:
pip install

in Python 3.16 will be sped up” if the proposal is accepted.

Rust API Sketch

David provided an example of some Rust code calling a hypothetical Rust API for Python. The API would use a Rust attribute (

Code:
#[pyfunction]

) and be similar to Argument Clinic, a development tool for automatically generating blocks of code for handling C function arguments from Pythonic function syntax. Rust functions would always be passed the thread and interpreter state (

Code:
Python<'_>

), use smart pointers around objects (

Code:
Py<...>

), and lean into Rust error handling with the

Code:
Result

enum, returning either a result or an error that was raised.

Code:
[code]#[pyfunction(signature = (
    data,
    /,
    wbits=MAX_WBITS,
    bufsize=DEF_BUF_SIZE,
))]
fn decompress(
    py: Python<'_>,
    data: Py,
    wbits: c_int,
    bufsize: isize
) -> PyResult, PyErrRaised> {

    // buf will be cleaned on scope exit
    let buf = PyObject::get_buffer(py, &data)?;
    let decoded = /* ... */;

    Ok(PyBytes::new(py, &decoded))
}[/code]

The example above shows a buffer being allocated and automatically cleaned up on scope exit, rather than being cleaned up manually as would be required when writing the same function in C.

Proposed success criteria

David moved on to success criteria: what would the Rust for CPython project need to show to move into new phases of the roadmap and eventually become a required part of building CPython? “For previous big changes like the JIT and free-threading, we’ve explicitly defined success criteria that would need to be met in order for the added complexity to be accepted”, David explained, “we expect we’d need to do the same here. What should those criteria be?”

David had these suggestions for core developers:

Critical: A majority of active core developers are open to using the Rust API to implement functionality.
No meaningful slowdown to CPython performance benchmarks.
All tiered platforms must be supported by Rust. The experience of distributors building CPython should generally indicate that adding Rust support is manageable.

David noted that the first point reads “open”, not “familiar”, and shared a plan to survey Python core developers about how they’ve used Rust while contributing to CPython when deciding whether to move Rust out of experimental stages.

Discussion

On the topic of designing the new Rust API so that it’s “familiar” to users of the C API, Thomas Wouters advised against “making compromises for the dinosaurs”, including himself in the subset, instead asking whether the Rust API should be designed from first principles. David responded that there are “places to lean into Rust”, such as dropping resources on scope exit, but there are also idiomatic Rust designs which “won’t be the best fit”. David noted that it would be reasonable for core developers to be looking at both the C and Rust API at the same time while working. “We should be mindful of our audience, which is also ourselves”.

Larry Hastings asked why the Rust for CPython project wasn’t a “rewrite”, suggesting the team “display your success as a fork”. David acknowledged that “RustPython already exists” and that the Rust for CPython team had already spoken with the contributors of the project. “RustPython isn’t as performant as CPython, but could be used to inform what APIs we design”.

Larry also shared that he “wasn’t super excited to learn Rust to work on CPython”. David assured him that there are many areas of CPython that would not be considered for writing in Rust: “CPython should not be written in Rust for the sake of Rust”. “CPython will be a dual-language project for a meaningful amount of time”. However, David cautioned that “it would be disingenuous to say that Rust would be optional forever”, as one of the aforementioned roadmap items for the Rust for CPython project is to become a required part of the build process and provide a public Rust API.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Pablo Galindo Salgado was more concerned about the future, which was “reaching for our dependencies from Cargo”, noting that this would be a “huge problem” and a potential “showstopper” for the project. “We vendor our dependencies, and we have a very selective set”, he said, noting that each time a vulnerability is published for one of those projects, the release managers need to make new releases, which can be “tiresome”. “Right now we’re only focusing on the APIs and the basics”, he added, highlighting that the challenge of taking on many Rust dependencies hasn’t been addressed yet.

David answered that the team should “select as few external dependencies as possible”; “zlib-rs is only one dependency”, and the Rust sources would be vendored so that “building CPython would not require Cargo”. David added that “Cargo has a relatively clean system for vendoring dependencies” and that the “Rust for CPython proof-of-concept uses this system”. The vendored sources “wouldn’t live in the CPython tree”. Łukasz Langa agreed that “it’s better for dependencies to live separately”, referencing the cpython-source-deps repository, with Thomas reminding everyone that this would be a new usage of that repository; today it is only used for binary installers of CPython.

[Py Blog] Memory Snapshots for CPython (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:04 -0200

If you open up a new Python interpreter, close it, and then open a new Python interpreter again… how different are these two processes? Hood Chatham’s talk at the Language Summit aimed to provide a safe alternate “bootstrapping” path for the Python interpreter that forgoes running the same initialization from scratch each time and instead uses a “snapshot” of the Python process memory after initialization has completed.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

In tests of snapshots in Pyodide, executing a simple “Hello, world” program was around 4 times faster (0.353 seconds versus 1.406 seconds) when loading the Python interpreter from a memory snapshot compared to loading the Python interpreter from scratch without a snapshot. Node.js implemented V8 snapshots in v4.2.4 and saw ~33% improvements to startup time, but shortly after, in v4.8.4, snapshots were disabled due to the problem that Hood wanted to raise for discussion.

Randomization where you don’t expect

The issue was one that was familiar to Python and many other languages: denial-of-service through hash algorithm collisions. This was a security issue reported to many programming languages at the same time, including Java, Ruby, PHP, and many other projects.

Python fixed this issue in Python 3.3, as did many other programming languages, by adding a random “salt” to hash() calculations. The salt is randomized at program startup to prevent remote attackers from controlling the hash values of inputs, and thus causing a CPU denial-of-service by creating extremely unbalanced data structures that rely on object hash values being evenly distributed, like dict and set.

The danger of snapshotting and restoring the memory of a Python process post-initialization is captured by Randall Munroe’s xkcd “Random Number” (image below licensed CC-BY-NC 2.5), where the fixed value of “4” was at some indeterminate time in the past chosen by a fair dice roll and is now reused whenever a new random number is requested.

If a Python process were to begin “restoring from a memory snapshot”, effectively this is what would happen for hash seed randomization: a value that is expected to be randomized every time would become deterministic and shared across all snapshots. Hood noted that there were likely other places, especially in libraries and programs, where this assumption would break existing use-cases, too.

Hood proposed that the concept of an “initialization phase” be added to the Python language model, citing RPython and SPy as two runtimes that have introduced an “explicit entrypoint to an initialization phase”. These entry points were useful for tree-shaking and pre-evaluation, respectively, but could be reused for the purpose of fixing issues related to adding memory snapshots to CPython. This initialization phase could be called again on re-initialization, allowing the runtime and third-party libraries to safely reintroduce randomness into the program if memory snapshotting were implemented.

Discussion

Photo by EuroPython (CC BY-NC-SA 4.0)

Stefan Behnel referenced some similar functionality that Python already provides: the atexit module, which provides an API for registering a callback function that is called when the Python process is exiting. Stefan wondered whether a

Code:
reinit

callback function could serve the needs Hood described.

Peter Bierma wondered whether improvements to initialization time could speed up startup enough that snapshotting would no longer be needed. Hood answered that there’s a “ton of work” to do when initializing Python, such as importing modules, and that a proposal to speed up initialization is “an order of magnitude more complex” than memory snapshotting and reinitialization. “I know how to implement snapshotting, I don’t know how to speed up the interpreter”.

Thomas Wouters wondered whether lazy imports, defined in PEP 810 and coming to Python 3.15, would solve some of the issues with slow initialization. Hood was cautious, stating that lazy imports might make his specific use-case “worse before it gets better”, especially if memory snapshots were implemented for Python. Lazy imports mean that imported modules aren’t parsed and executed until a member of the module is accessed, so if an import isn’t required for a particular execution of a Python program, then its cost isn’t paid by the interpreter.

Snapshots, however, benefit performance because the cost to parse and execute all imports is paid a single time, the state is saved, and then it is “restored” in future executions to skip this part of the process. If imports aren’t resolved initially (such as when lazy imports are used), then the imports won’t be saved in the snapshot, and their cost will be paid on each Python execution, even if memory snapshots are implemented.

Hood also shared some details about the use-case he was interested in: using Python with WebAssembly and edge compute services. Edge compute services don’t necessarily have access to a filesystem at runtime, which lazy imports would require.

The conversation switched to freezing modules. Pablo Galindo Salgado referenced some prior art at Alibaba for snapshots using a “memory dump and metadata table”. Guido van Rossum, speaking from experience on the Faster CPython team, noted that deep-freezing modules “didn’t affect startup that much” while adding complexity, and so “wasn’t worth it” from the team’s perspective. The team “didn’t spend much time trying to figure out why” this didn’t affect startup times.

Eric Snow added that another approach considered was freezing the memory of objects and introducing a “form of copy-on-write (COW)”, acknowledging that many objects aren’t going to change, so copying data can be avoided.

[Py Blog] Memory Buffer Protocol (Python Language Summit 2026)

Wed, 30 Sep 2026 10:00:03 -0200

The Python Buffer Protocol defines the semantics for accessing the underlying memory buffer of Python objects such as

Code:
bytes

Code:
bytearray

, and other types like

Code:
array.array

. The Python Buffer Protocol allows accessing an implementing object’s underlying memory directly, rather than only through higher-level APIs, which improves performance.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Documenting the Buffer Protocol

Nathan Goldbaum opened with some suggestions that were unlikely to be controversial, like improving the documentation and making the Buffer Protocol specification less fragmented. Buffers support a “struct-style” language that is similar to, but much more featureful than, Python’s struct format strings. “There are corners of the format language that are underspecified”.

Today, users are expected to read PEP 3118 or implementations like NumPy to understand the full grammar, “including records, field names, subarrays, byte order, alignment, and complex numbers”. Documenting all features within the Python documentation would be a meaningful improvement.

Continuing with helping consumers of the Buffer Protocol, Nathan proposed creating a HOWTO guide for exporters and consumers of the Buffer Protocol, citing a lack of “complete examples” in C that implement validation, cleanup, ownership, and safe use of threads.

Safe concurrency

Nathan was primarily looking for feedback on the upcoming sections of the talk, for which there are drafted PEPs addressing two shortcomings of the Buffer Protocol: coordinating concurrent reads and writes and custom data types.

The first issue was that the Python Buffer Protocol “didn’t support read and write coordination at the protocol level”. Storage addresses were stable, but contents were not. The Buffer Protocol supports a

Code:
readonly

attribute, but this value only applies to a single view, and writable access could not be made exclusive with existing APIs.

Nathan’s proposal to add safe coordination of reads and writes was through new buffer “leasing” C APIs,

Code:
PyBufferLease

and

Code:
PyBufferAccessState

, similar to Rust’s borrowing mechanism. These APIs would allow consumers to lease a buffer and declare their access pattern ahead of accessing a buffer view. Below is an example of how these new APIs would be used:

Code:
[code]PyBufferLease *lease = PyObject_AcquireBufferLease(obj,
                                                   PyBUF_CONTIG_RO,
                                                   Py_BUFFER_ACCESS_SHARED_READ);

if (lease == NULL) {
    return -1;
}

const Py_buffer *view = PyBufferLease_GetView(lease);

Py_BEGIN_ALLOW_THREADS
consume_bytes(view->buf, view->len);
Py_END_ALLOW_THREADS

PyBufferLease_Release(lease);[/code]

Leases could be opened in either

Code:
SHARED_READ

Code:
EXCLUSIVE_WRITE

mode, and calling

Code:
PyObject_AcquireBufferLease()

would not block, instead immediately either succeeding or failing if an incompatible lease already exists.

Code:
EXCLUSIVE_WRITE

would provide writable access and exclude every other access to overlapping memory.

The existing PyObject_GetBuffer(), PyBuffer_Release(), and other related interfaces would remain unchanged under Nathan’s proposal. Buffer exporters would advertise explicit support for the new access modes, and exporters that don’t support the new access APIs would continue to use existing APIs as-is. Consumers would query the exporter using

Code:
PyObject_GetBufferAccessModes()

and use a lease if the desired access mode is available from the exporter.

There is already an implementation being worked on that is similar to this proposal. Kumar Aditya is working on changes to NumPy allowing interoperability with the PEP, but Nathan noted that NumPy allowing access to raw pointers presented an “interesting” challenge.

Nathan published his PEP draft, is requesting feedback, and will open a PEP discussion soon.

Custom Data Types

Finally, Nathan detailed a proposal that he and Sebastian Berg created that would add an extension point to the Buffer Protocol for custom data types. Today the Buffer Protocol format has a “fixed vocabulary”, meaning that to support custom data types, third parties either need to land a new type and format code in Python or use “out-of-band signaling and convention”. Instead of needing to block new types and format codes on a decision from the Python Steering Council, a namespace-based approach to custom data types could be used.

In this proposed extension, a custom data type would be defined with square brackets (

Code:
[]

) with a

Code:
$

character delimiting the library namespace from the data type. Implementations that support the definition could then interpret known custom data types safely and reject any unknown custom data types without parsing the buffer.

Nathan pointed to a discussion on discuss.python.org and the draft PEP for this proposal.

Discussion

Photo by EuroPython (CC BY-NC-SA 4.0)

Petr Viktorin asked whether a new API was needed for this proposal or whether the existing

Code:
PyObject_GetBuffer()

API could be extended. Nathan didn’t think the existing API, which is a part of Python’s Stable ABI and therefore can’t be changed, had enough space for a new field. “There’s an internal field, but it’s documented as being used by exporters, so we can’t use that one”. “We can’t smuggle information in the struct, we’d need a new struct to hold that information.”

Thomas Wouters asked how Nathan’s proposal compares to Rust: when asking for exclusive write access, should the request block or error out? Nathan replied that erroring out would be the simplest implementation. David Hewitt asked about the composability of the implementation, and whether it could accommodate additional, likely desirable features like “blocking, asynchronously blocking, or more complicated structures like writing to slices”.

Larry Hastings wondered whether this new API assumes that users are being diligent and using the API correctly. Nathan confirmed that memory corruption would be possible if the APIs were used incorrectly, but that pure-Python users wouldn’t be able to do this, only authors of C extensions. Leaking memory wouldn’t be possible.

Photo by Hugo van Kemenade (CC BY-NC-SA 4.0)

Hood Chatham asked whether buffer exporters would be allowed to reject consumers using the old buffer access pattern without specifying either

Code:
SHARED_READ

Code:
EXCLUSIVE_WRITE

. Doing this would enable using a Rust buffer as the backing storage.