Thursday, June 12, 2025

2025 PSF Board Election Schedule

The PSF Board elections are a chance for the community to choose representatives to help the Python Software Foundation create a vision for and build the future of the Python community. This year, there are 4 seats open on the PSF Board. Check out who is currently on the board on the PSF's website. (Dawn Wages, Jannis Leidel, Kushal Das, and Simon Willison are at the end of their current terms.) As we previously shared, the Board election will take place a little later this year to better serve our community and ease pressure on PSF Staff. 

Board Election Timeline

  • Nominations open: Tuesday, July 29th, 2:00 pm UTC
  • Nomination cut-off: Tuesday, August 12th, 2:00 pm UTC
  • Announce candidates: Thursday, August 14th
  • Voter affirmation cut-off: Tuesday, August 22nd, 2:00 pm UTC
  • Voting start date: Tuesday, September 2nd, 2:00 pm UTC
  • Voting end date: Tuesday, September 16th, 2:00 pm UTC

Voting 

You must be a Contributing, Supporting, or Fellow member by August 22nd and affirm your intention to vote to participate in this election. If you are currently a Managing member, you will receive a communication soon notifying you that your membership type will be changed to Contributing per last year’s Bylaw change that merged Managing and Contributing memberships

Check out the PSF membership page to learn more about membership classes and benefits. You can affirm your voting intention by following the steps in our video tutorial:

  • Log in to psfmember.org
  • Check your eligibility to vote (You must be a Contributing, Supporting, or Fellow member) 
  • Choose “Voting Affirmation” at the top right
  • Select your preferred intention for voting in 2025
  • Click the “Submit” button

Per another recent Bylaw change that allows for simplifying the voter affirmation process by treating past voting activity as intent to continue voting, if you cast your ballot last year, you will automatically be added to the 2025 voter roll. Please note that if you removed or changed your email on psfmember.org, you may not automatically be added to this year's voter roll. 

If you have questions about membership, please email psf-elections@pyfound.org.

Run for the Board

Who runs for the board? People who care about the Python community, who want to see it flourish and grow, and also have a few hours a month to attend regular meetings, serve on committees, participate in conversations, and promote the Python community. Want to learn more about being on the PSF Board? Check out the following resources to learn more about the PSF, as well as what being a part of the PSF Board entails:

You can nominate yourself or someone else. We would encourage you to reach out to folks before you nominate them to make sure they are enthusiastic about the potential of joining the Board. Nominations open on Tuesday, July 29th, 2:00 pm UTC, so you have time to talk with potential nominees, research the role, and craft a nomination statement for yourself or others. Take a look at last year’s nomination statements for reference. 

Learn more and join the discussion

You are welcome to join the discussion about the PSF Board election on the Discuss forum. This year, we’ll also be hosting PSF Board Office Hours on the PSF Discord in July and August to answer questions about running for and serving on the board. Subscribe to the PSF blog or, if you're a member, join the psf-member-announce mailing list to receive updates leading up to the election.

The Python Language Summit 2025

The Python Language Summit 2025 occurred on May 14th in Pittsburgh, Pennsylvania. Core developers and special guests from around the world gathered in one room for an entire day of presentations and discussions about the future of the Python programming language.

The summit was organized by Emily Morehouse and Łukasz Langa, and blog posts were written by Seth Larson. Thanks to Marie Nordin, the Community Communications Manager at the Python Software Foundation, for reviewing and editing the blog posts.

This year’s set of presentations was heavily themed towards the new "free-threading" work, featuring multiple discussions about contention, concurrency, and governance.

Attendees of the Python Language Summit 2025


Please enjoy the blog posts about each topic below:




The Python Language Summit 2025: How can we make Breaking Changes Less Painful?

The first talk of the Python Language Summit was delivered by Itamar Oren. Itamar has plenty of experience at Meta deploying massive amounts of Python code to production. Itamar’s presentation focused on how Python core developers might make upgrades to Python versions smoother for users in the face of breaking changes to the language and standard library. Itamar shared that “not all breaking changes are equal” and suggested adopting a taxonomy of breaking changes and how much and when they would affect users.

Itamar made it clear that he was “not asking [Python core developers] to do fewer breaking changes”, but instead hoped to make breaking changes easier for users to work through during a Python version upgrade.

Users upgrading Python versions need to go through a flowchart for each breaking change:

  • Awareness of breaking changes
  • Finding the affected code
  • Fixing the affected code
  • Verifying fixes are correct

Starting with “Fixing”, Itamar noted that “fixing the code tends to be the easiest step, but easy at scale is still hard” and that fixing was easiest when you know where to do the fix. This was especially straightforward if the fix only used builtins or the standard library, noting that needing to take on new dependencies like packages on PyPI for removed modules was much more difficult.

“Migration guides are great, let’s do more of them”, Itamar said while thanking Barry for the imp module migration guide. Itamar called out a few suggestions for would-be migration guide authors, such as making the guide comprehensive for all removed APIs and providing an indication “whether an API is a drop-in equivalent or requires further changes”. Itamar gave the example of imp.load_module() versus importlib.import_module(), which was recommended in the migration guide but had different function signatures and couldn’t accomplish the same tasks.

Itamar noted the difficulty in finding the documentation for deprecated and removed modules because, after a module is removed, its corresponding documentation on docs.python.org is also removed for that version. Carol Willing noted that the documentation team has been working on fixing the documentation removal issue for the “past 3 months”.

Finding code that’s affected by breaking changes was the toughest challenge, as breaking changes all had different “findability” metrics ranging between “easy" and "virtually impossible”. The easiest breaking changes to find in massive codebases are statically discoverable, such as being able to parse Python source code using an Abstract Syntax Tree (AST) or regular expressions to quickly hone in on problematic code.

The next easiest class of breaking changes to find are those that manifest at “build time”, which, since Python is an interpreted language, build time is equivalent to when PYC files are compiled. Itamar noted that “real code has good coverage for these issues”, like errors that happen on import time. The example noted for this type of breaking change was the accidental dataclasses mutables change in 3.12.

The most difficult class of breaking changes manifest during runtime, such as failures that depend on type or value information for parameters. These breaking changes are most likely to cause production outages because whether you find the affected code or not is dependent on type checking and test failures, which can be “highly variable”.

Itamar finished the presentation with a handful of suggestions for core developers on how to improve the backwards-incompatible change process. These suggestions included creating a taxonomy for breaking changes in terms of discoverability and fixability, and suggesting tools for automatically fixing backwards incompatible changes during upgrades. Ruff was suggested as a potential tool for applying these automatic fixes.

Discussion

Eric Smith spoke about the dataclasses mutability change, noting that he and Raymond Hettinger had made the change and “didn’t recall getting any feedback until we released it, at which point we couldn’t fix it”. Eric wasn’t sure what he could have done for that specific case, but “thought that we are getting better at people using new versions during the beta period”. Eric also lamented that the change “would have been backed out had [he] known about the breakage”. Itamar suggested that core developers might collaborate with companies with large codebases for testing changes when core developers aren’t sure about compatibility.

Alex Waygood spoke about maintaining the typing-extensions project, which suffered from backwards compatibility issues, noting that “not many projects pin typing-extensions”, meaning the subtle changes end up breaking in surprising ways. Notably, typing-extensions broke Pydantic in the past, which caused problems for typing-extensions maintainers. Alex offered that “running the test suites of several large packages that depend on [typing-extensions] has helped catch many changes that weren’t expected to be backwards incompatible”, adding that “it would be great if there were an easier way to run the test suite of other projects”.

Carol Willing suggested working on making Python pre-releases easier to run using Continuous Integration (CI) and that this approach had been “successful” for scientific Python projects for finding and fixing breaking changes ahead of when the changes start affecting users. Itamar concurred, saying his “dream is to run global testing against [Python main branch] on a daily basis” but that this dream was “currently impossible” due to third-party dependencies. Pradyun Gedam noted that the idea of “ecosystem tests” had been discussed on the Packaging Discourse.


The Python Language Summit 2025: An Uncontentious Talk about Contention

 An Uncontentious Talk about Contention

Mark Shannon presented to the Language Summit a talk about contention, noting that the talk had been upgraded from a lightning talk, so warned the audience that there was “now some room for contentiousness”.

Counter program showing 10 threads concurrently incrementing a value 100,000 times, hoping for a total value of 1 million.

“Is this program thread safe? It depends!” 😱

“Thread-safety is a property of the program and the implementation! You can’t tell if a program is thread-safe unless you know both.” If the program is running on Python 3.10 and later, the program prints the expected “1 million” because of context-switching in the Global Interpreter Lock (GIL). If the program is run using Python 3.9 or with free-threading enabled, the program prints “random nonsense”.

Mark shared a diagram of the “synchronization quadrants” from Kevlin Henney, where the vertical axes are “Mutable” and “Immutable”, and the horizontal axes are “Unshared” and “Shared”. The top-right quadrant corresponding to “Mutable and Shared” is red and shows that “Synchronization is required,” where all other quadrants show that “Synchronization not required”.

“With sharing and mutability, bad things happen”, and unfortunately, if we want parallelism in Python, “a lot happens in [the shared mutable] quadrant”. We need to move stuff either down (towards immutability) or left (towards unshared). So, how can we do that in Python? Mark gave examples:

  • Data structures that are immutable, today Python only provides frozenset and tuple. Could add more data structures for immutability.
  • Data locality, which means only accessing data from one thread.
  • Serialization, which is “locks”, including “the lock” (GIL), which Mark considers “underrated”.
  • Regions, which is an area of code or data where there is serial execution. Currently, the only robust way of implementing regions beyond “strong discipline” is using multiple interpreters.
  • Stop-the-world mutability, which Mark describes as “switching between the bottom-right (shared and immutable) and the top-left (unshared and mutable). This is already used in some places for free-threading.

Stop-the-world mutability will be relevant in the future as “Python types and modules have to be shared but also break the language if they are immutable”. “There is opportunity for deadlocks and the process is not theoretically sound, but [stop-the-world mutability] is reasonably effective in practice”. The biggest downside is that “it’s very slow to mutate these objects, you don’t want to [mutate] often”.

Mark then warned the audience that we were leaving the “fact” section of the talk and entering into the “opinion” section with what he believed Python ought to do.

Short-term: More immutability!

In the short term, Mark posited that “regardless of the concurrency models we have, more immutability is good”. There are C APIs that allow mutation of objects that “really shouldn’t be mutated,” like strings and tuples.

Mark also pointed out places where mutability is allowed today, “because [the objects] were mutable before, but not for any good reason,” like functions and class method resolution order (MRO). Mark was “sure that people use [this mutability property] because it is possible, but not for good reasons”.

Mark suggested adding “freezing” methods to data structures like bytearrays, lists, and dictionaries to allow sharing these objects without worrying whether another thread would modify them. Barry Warsaw brought up that he had proposed a “freeze protocol,” which was rejected back in 2005. Barry asked whether the PEP should be brought back, which Mark agreed with, although the details as to why the PEP was rejected weren’t immediately clear.

Finally, Mark suggested making modules and classes “stop-the-world mutable”.

Long-term: Robust model of parallelism

Long-term, Mark wanted to see a “robust model for parallelism” in Python. There are a few models out there, like OCaml, which “is a functional language that has mutability and previously was single-threaded”. OCaml’s model where they have keywords like “local” and “shared” with “well-defined transitions”. Mark’s other example was an upcoming talk at the Language Summit, specifically free-threading.

Mark posited that “by default, code that isn’t safe should raise an exception” and that there “should not be any accidentally unsafe code,” pointing to Rust and Haskell, which allow programmers to explicitly disable safety using specific keywords like “unsafe”. Mark closed by quoting the Zen of Python, “that errors should not pass silently,” where “race conditions are silent errors” and to “avoid guessing” where “race conditions are just guesses”.

Discussion

Thomas Wouters wanted to “push back” on the notion that users shouldn’t be using the mutability of functions, for example. “These are properties that not only are actively used in order to create new things. Rewriting bytecode is how popular packages in the Python community actively work, we can’t break them”. Guido van Rossum countered, saying that rewriting bytecode already “breaks every Python version”, which Thomas agreed with, saying that “this is understood as being part of the deal. Making function objects immutable means they need an entirely different approach”.

Pablo Galindo Salgado called out the importance of understanding how and why people are using (or abusing) an API to provide a better experience. Pablo wanted to understand use-cases because oftentimes users “didn’t want to do what they were doing” and understanding use-cases meant “[core developers] can add something better”. He added, “We cannot blanket approve every usage of a language as a feature”.

Sam Gross didn’t think that making functions immutable would make free-threading much better, and that stop-the-world immutability doesn’t seem worth the backwards incompatibility pain.

Martin DeMello asked Mark's proposal for making race conditions into exceptions, to which Mark quickly brought up a slide with a code example that included a “RaceConditionException,” which garnered a chuckle from the room. “This is what it would look like”, replied Mark, “but how [the exception] would be implemented depends on the [parallelism model], which is why we need those models”. Martin remarked that this seems like it would be difficult, to which Mark agreed, “This is not an easy change”.

Sam added that Rust and other languages don’t prevent race conditions, they only prevent data races, and that “in practice helps catch bugs statically,” it doesn’t actually make Rust code thread-safe. “You still have to think about high-level things, but it doesn’t prevent all bugs and race conditions”.


The Python Language Summit 2025: State of Free-Threaded Python

“Does it make sense to move to the next phase of PEP 703?”, core developer Matt Page opened his presentation to the Language Summit. Free-Threaded Python has come far since the last Language Summit, where Daniele Parmeggiani presented on free-threaded Python using the then-newly-added “--disable-gil” option.

Matt had prepared a status report for free-threaded Python on all of the axes that PEP 703’s acceptance had laid out: Performance, Stability, Maintainability, and Adoption, and wanted to ask core developers when the PEP should proceed to the next stages.

Performance

The performance gap for free-threaded and non-free-threaded Python was 40% in Python 3.13. This has been reduced to less than 10% for most platforms, and the gap is platform-dependent. For macOS, there is not much difference, but for Ubuntu and Windows, the gap is around 7-8% slower for single-threaded workloads. Matt stressed that these values are “point-in-time” and that the team will keep working on them, but “will eventually reach a point of diminishing returns”.

Matt added that the memory overhead was more substantial at 20% more for pyperformance workloads compared to without free-threading, but that the team “was just starting to work on this”. Matt suspected that the memory overhead was “mostly fixed” and thus “would be a smaller percentage overhead in real workloads”.

Stability

Matt shared that the architectural changes for free-threaded Python had all been completed and that none of the reported issues “required any large architecture changes”. “[Sam’s] design has proven to be sound, which is great for the future”. The issues that are reported are not disproportionate compared to bugs reported about the rest of the CPython project, and “around half of the issues are data races reported by [ThreadSanitizer], which are easier to fix”.

The remaining work is creating a Stable ABI for free-threading and continuing to fix thread-safety issues with standard library modules. The most popular areas of Python, like dictionaries and lists, are already thread-safe, but the team still has to “work through the long-tail” of APIs.

Maintainability

Matt acknowledged that free-threaded Python was a step-function of complexity and asked, “Can core developers support this complexity?” Matt noted that the set of contributors to free-threaded Python architecture was small but growing. Luckily, “the complexity is well-contained. Most people won’t need to touch free-threaded code and most core developers will only interact with critical sections which are well-documented”. Matt shared that there is “comprehensive documentation” for both core developers and users looking to parallelize workloads.

Adoption

Quansight Labs has created a resource page available for users trying out free-threaded Python or migrating their code and extension modules to support free-threaded Python. There’s also a Discord channel and Threading category on the Python Discourse for users looking for help. The resource page also hosts a free-threading compatibility status for important Python packages and tools.

Matt also shared another compatibility status tracker created by Hugo van Kemenade that automatically updates based on the availability of free-threaded wheels (wheels with an ABI tag that ends in “t” like “cp13t”) for popular Python packages with extension modules. The current status was around ⅙ of the top 360 projects on PyPI, with extension modules supporting free-threading, notably popular scientific packages like numpy, pandas, and scipy.

Matt also recommended anyone interested in more about community adoption to watch Lysandros Nikolaou and Nathan Goldbaum’s talk at PyCon US titled “Unraveling Community Support for Free-Threaded Python”. The recording is now available on YouTube.

Matt asked for a few outcomes from the free-threading discussions at the Language Summit. Firstly, Matt hoped that core developers might start thinking about free-threading from the beginning when designing and developing new language features. He followed up with a suggestion to focus on performance and correctness when free-threading is enabled.

Secondly, Matt was hoping to receive a signal for the community that free-threading was not going to disappear suddenly. “We need to see more people using [free-threading] to find the next set of bugs and to test the implementation”, Matt continued, “and if [free-threading] has an air of experimentality, it’s harder to justify adopting [free-threading]”.

The current status of PEP 703 is that free-threading has been conditionally accepted by the Steering Council, and that the ability to back out all free-threading code from CPython is reserved by the Steering Council in case there are problems with the implementation. That status hasn’t materially changed since the PEP’s conditional acceptance.

Matt concluded his presentation by asking whether the Steering Council and core developers had thoughts or concerns on proceeding to the next stage of PEP 703 and free-threading.

Discussion

Core developer Eric Smith asked whether removing the Global Interpreter Lock (GIL) would cause a “permanent mental overhead for core developers” and asked how often other core developers made a change in Python that broke free-threading. Matt shared that this situation was “pretty rare so far,” especially beyond ThreadSanitizer failures.

“At the C-layer, you already had to think about the GIL potentially getting released”, commented Thomas Wouters, “...cases that were protected by the GIL before PEP 703 can now easily be protected by critical sections”. Thomas added, “There are cases where you need to think about [free-threading], but for the most part it’s not that big of a deal” and “The tools from PEP 703 make it not hard to write correct code, even under free-threading”.

Brandt Bucher pushed back on Thomas’s comments that the interpreter already had to worry about reentrant code, saying that free-threading is another flavor and that there definitely is “mental overhead” and an “ongoing concern and constant friction”. Especially in previously straightforward cases like getting an item from a list.

Brandt asked whether 16% of PyPI packages supporting free-threading was enough to say that free-threading couldn’t become a “rugpull” situation, and if not, “what number would the Steering Council be comfortable with?” Brandt also identified that not only the availability of free-threaded wheels, but also their usage through downloads should be examined, to see whether free-threading was being used in the real world.

Brandt also commented on unmaintained packages with extensions that “would never be thread-safe”. Brandt asked whether the plan was to keep the functionality that falls back to using the GIL when a module isn’t marked as free-threading safe. Sam Gross confirmed that “[he] didn’t see any reason to remove the optional GIL”, even when free-threading became the default.

When asked about thread-safe containers and data structures for users, Matt answered that “they wanted to provide thread-safe data structures”, but that it “hasn’t been a focus right now” and that the work would likely start as a package on PyPI before moving to the standard library after “getting the abstractions right”.

Gregory Smith, introducing himself as a “token” Steering Council member, said he wanted to “listen to what other [core developers] are saying at the Language Summit and PyCon US” and to get a “vibe check” about how free-threading is going. Greg shared that the Steering Council was “waiting for the end of PyCon US to give an update on [PEP 703]” and that the current status is a bit of a “chicken and egg” situation between the experimental labeling and whether users can expect free-threading in the future to drive more adoption.

Thomas provided his perspective that “maintainability” was the biggest question in his mind. The number of projects going on, JIT, faster CPython, free-threading, general interpreter development, that it is “probably inevitable there’ll be times with proposed changes that these projects will be brought into conflict”. Thomas highlighted the need for a way to resolve the tradeoffs, like performance versus stable free-threading, and that “as a community, we need to own the shared responsibility that the entire ecosystem works”.

Pablo Galindo Salgado, who is also a Steering Council member, was concerned that we were seeing the “easy part” of free-threading adoption. “Numpy and the interpreter are receiving lots of support from people who know what they’re doing”. Pablo was curious how the work to adopt free-threading in other extensions would proceed without this expertise and resourcing. Pablo didn’t think this was a blocker for free-threading, but “made him less enthusiastic about the message to ‘just do it’” and would like to avoid a situation where a decision is made but then the “long-tail of adoption takes forever because we didn’t understand how to drive [adoption]”.

Thomas agreed that more documentation was needed on how to debug issues like ThreadSanitizer, to set expectations for users and library maintainers, and to build tools for thread-safety for libraries and users. Thomas felt confident that this would get done and that “the work isn’t unknown work, we know what we need to do”.

“I think we’re on that precipice of scientific Python really embracing more of the free-threading” said Carol Willing, recalling the infamous Python 2 to 3 transition for scientific Python projects “which was the initial driver for greater adoption of Python 3”. Carol hoped that there would be a huge push this year on free-threading and building on the awareness and the documentation: “I was always skeptical of whether we would get the social things in-place, and I think we are and we’re doing it well.”


The Python Language Summit 2025: Fearless Concurrency

Tobias Wrigstad, Matthew Parkinson, and Fridtjof Stoldt attended their first Python Language Summit to talk about some new concurrency concepts with core developers. Their slides have great diagrams, so I recommend checking them out. Tobias delivered the presentation to core developers, opening with a “potentially contentious statement” that “[data races and concurrency bugs] were the future that free-threaded Python programmers would see if free-threading was adopted for Python programs”.

“Off to the data races!”

The issue is when a value, such as “A” in the above diagram, is shared across multiple threads and written concurrently. “There is no easy way to tell when an object is shared. In the worst case, you have to read the whole program”.

These data-race bugs are also difficult to resolve using existing tools like “ChatGPT or StackOverflow,” which are only able to solve “syntax-driven problems,” and only after drawing the object graph do we see problems. Tools like ThreadSanitizer (TSan) can help, “but you first need to understand that you need to use a tool”. “As a Python programmer, I’m assuming this is not in your typical toolchain”.

Tobias continued, “The PEP 703 work has shown that it’s costly for the runtime to protect itself against racing code. Can we lift this problem up and talk about this problem at the Python level and make Python data-race free? Can we get an exception instead of a race?”

Deep Immutability

Referencing the “freezing” proposal that Mark Shannon had spoken about just hours ago in his Language Summit talk “An Uncontentious Talk about Contention”, “deep immutability” is one option for resolving data races in Python. Some performance improvements could be gained by adopting this model.

This model makes “all shared data immutable” so “there can be no data races” and is “trivial to check at runtime”. However, to do so would require sacrificing mutability, which is “common in Python programs”. “More immutability is great, but it’s not a solution to all our problems.”

Rust’s ownership model

“If we squint a little bit, we can explain Rust’s ownership model as ‘objects with a reference count greater than 1 cannot be mutated’”, Tobias explained. Rust’s ownership model allows for mutable objects as long as an object isn’t referenced more than once.

Adopting Rust’s model would require a “move operator” which, when used, “torches the original reference” and moves the reference to a new owner. This operator provides a safe transfer of mutable objects when a reference count is exactly 1.

However, “the same rule that prevents Y being assigned to X prevents nice things that people like to do”. This approach would “massively restrict which object graphs are valid” and “many Python object graphs in practice don’t look like this”, instead usually containing “reference loops”. Adopting the Rust ownership model in Python would “require rewriting most existing Python programs”.

Region-based ownership model

The group proposed instead a “region-based model” they had designed called “Lungfish” that is “more permissive than Rust’s data model” but is “still data-race free”. 

Regions are “namespaces for data”. Regions are a group of mutable objects that are isolated from the outside, and all contained objects are shared, transferred, or frozen altogether. Regions can be nested within other regions, too.

Can’t move Region “r” to thread “2” because the borrow count is not 1.

Regions are “an enclosure of objects” that is tracked by their “borrow count”, which is the number of references that are “pointing into a region”. Objects are “slurped” (technical term) into a Region, and the borrow count increases for each reference pointing into the region. Regions can only be “moved” when the borrow count is 1, and any moves that don’t have a borrow count of 1 indicate a data race and should raise an exception.


Threads 1 and 2 share region r, where thread 1 holds the lock with access to the referenced region r, and has two references from X to A and Z to 42. Hence, the borrow count of 3.

Another option is to share the ownership of a region between two or more threads. Doing so would “move the ownership of the region within a lock shared between threads”. “When a thread owns the lock, then that thread can create points within the region and access the data, and the borrow count increments”. This borrow count increment needs to happen to track when the thread can release the lock safely, meaning there are the correct number of references to objects within the region.

What’s next for Lungfish and “Fearless Python”?

The group has a plan to introduce Lungfish and its concepts to Python through a “series of four Python Enhancement Proposals (PEPs)”. The order and current status of each PEP is the following:

  • The first PEP is for “deep immutability” and was “almost finished with 99% of tests passing on Python 3.12”. The team plans to upgrade to 3.13 and then submit the PEP.
  • The second PEP would propose “cyclic immutable garbage with reference counting” and also “adding atomic reference counting for the new immutable objects”. This PEP is around 80% done.
  • The third PEP would be for “sharing immutable data between threads and subinterpreters (PEP 734). Tobias added that “subinterpreters can be a good delivery model for some concurrency model on top of [subinterpreters]”. This PEP and project are around 50% done.
  • The fourth PEP would add sharing mutable data between threads and subinterpreters using Regions.

Tobias closed by sharing why the project was named “Lungfish”: “the project can be used with or without GIL(s)” (pronounced “gills”), which was received with equal parts laughter and groans at the pun.

Discussion

Barry Warsaw asked, “Would regions be a first-class data object in Python? Tobias answered “yes”, the proposal included a “Region()” object that can be assigned names like so:

r = Region()
r.f = 42

Thomas Wouters wondered “whether regions would get used ubiquitously”, asking “which region does the sys module live in?” as a particularly difficult example. The group answered that they “are not sure what the answer is” and that there “are some concurrency issues there” and “that you want [the sys module] to be in a REPL thread”. “People in this room probably have better ideas here”.

David Hewitt, maintainer of the Rust PyO3 project, contrasted the proposed Region object with Rust’s “mutex” type and Python’s “Lock” type. Python’s Lock type doesn’t protect any data inside the lock, whereas Rust’s mutex type does protect data within the mutex. Rust’s mutex allows taking the data out of the mutex if you own the mutex, changing the mutability, and more, similar to Regions. David “has become familiar with the mutexes in Rust, and coming back to Python’s locks feels like a bit of a paper cut”.

David asked whether, instead of “introducing a new concept with Regions,” the three would introduce the concept more similar to a Rust mutex instead. Tobias answered that the protection mirrors the mutex, but that Regions uniquely allow nesting “to build a tree of regions” and a “notion of transitive closure of state in the object graph” that “transcends its use within a mutex, such as when the region is transferred or how freezing propagates within a region”. “Mutexes are one use of a Region, but not the only use”.

Donghee Na asked about the stability of existing behavior. Fridtjof answered that the three “had added tests specifically for the new behavior of immutability”, saying that the “immutability and freezing feature branches are really solid” and that the region feature branch is “more experimental”.

Donghee continued and asked whether the community would need to modify its code. Tobias answered, “Yes, if they want to take advantage of the benefits”. Matthew answered, “Pure Python can directly support regions, if you have a C library, then you’d need to add some modifications to your code to benefit”.

“C libraries would be an opt-in model at the module level”. This is similar to free-threading, where modules need to opt in; otherwise, the runtime doesn’t run with free-threading. “When you freeze an object graph, if [the runtime] encountered an object that doesn’t implement freezing, then you backtrack the freezing”. “You would need to register your types as freezeable”.

Martin DeMello asked whether freezing a region was a “one-way operation,” noting that freezing a region removes the object graph. Tobias answered that at the moment, “it does not allow [frozen objects] to be mutated until [the frozen objects] hit the finalizer, which turns objects back to be mutable again”. “We could do something like you’re proposing, I’m just worried,” with laughter at the mention of the finalizer. Tobias added a comment about “a potential copy-on-write” type to allow users to enable this use case.

Pablo Galindo Salgado asked about C extensions, “If I incref (increase a reference count), how does the region know whether this is an internal reference or an external reference?” Fridtjof replied that “there are two answers”, first being that “if the C extension had opted in, the system assumes that [the C extension author] is doing the right things” which in Pablo’s case would require a PyRegion_IncRef() function or similar. The second answer is that if the C extension doesn’t opt in, the system would be able to “reestablish the borrow count” for “backwards compatibility” by “leveraging the garbage collection mechanism that’s already there”.

Overall, there was definitely interest in the trio’s proposal from core developers due to the new problems that free-threaded Python will bring to Python users regarding concurrency.


The Python Language Summit 2025: Challenges of the Steering Council

Eric Snow opened his presentation about the Python Steering Council with an appreciation of current and former Steering Council members and all their hard work, which was met with applause from Language Summit attendees. “... and the same goes for Guido, who took 5 people to replace”.

“We’ve had several years of experience with the Steering Council”, Eric opened, “this discussion is meant to be an opportunity to talk about and identify ways to make the Steering Council better”.

Eric started by listing the aspects of the Steering Council that have worked, “the language and its projects haven’t stagnated”, many PEPs have been finalized, “and most notably, sensitive issues have come up and the Steering Council has demonstrated leadership”.

In Eric’s opinion, the biggest issue was that he had been “surprised” by some responses from the Steering Council. What factors make the work of the Steering Council difficult? “...being diligent about being fair and united, which takes time and effort”.

“Effort and time are limited resources for volunteers”. Eric identified that in addition to managing the language, the Steering Council has to spend time managing the Developers’ in Residence, doing community outreach, addressing Code of Conduct violations, and creating presentations for PyCon US.

“There’s a temptation to compare core development under Guido to core development under the Steering Council,” Eric admitted he’s caught himself doing in the past. “The comparison isn’t helpful or fair”.

For Eric, it isn’t always clear whether the Steering Council is the voice of consensus or whether they are the deciders. The Steering Council is “inherently a bottleneck of core development”. “The nature of committee work combined with a volunteer schedule means it can take a while to discuss and reach a decision”. This directly impacts the pace of runtime development.

Eric also highlighted that “there’s a [latency] penalty for PEP authors whenever there is a new Steering Council,” which, according to PEP 13, happens on a yearly cadence. This is despite having a relatively consistent set of people on the Steering Council year-over-year. Eric called out his own PEP 554, being particularly affected by the Steering Council turnover.

“It’s difficult to not have feedback from [the Steering Council] in the midst of discussion thinking that there was consensus or that issues had settled only to be surprised by a later response from the Steering Council”. Eric shared that this had happened multiple times to him in the past and called the experience “deflating”. Eric said it seemed important to have a “sense of where the Steering Council or a delegate was on discussions as they unfolded”.

Eric was looking to discuss potential improvements, and he noted there had been a few in the past, including delegating decision-making and publishing notes.

Discussion

Carol Willing, inaugural Steering Council member, commended Eric on “[doing] a great job putting together a positive presentation about the challenges”. What Carol remembered from the first Steering Council was thinking “there’s a ton of stuff to do and [she couldn’t] believe Guido was doing all of this on his own”. Carol identified that project management had become the biggest issue and that a “secretary or assistant role wasn’t the right terminology”. “It’s time to revisit the workload… [the problems] are largely due to the volume of stuff on the Steering Council’s plate”.

Brandt Bucher felt that the Steering Council appeared to have a policy of “don’t participate in discussions and only speak with one voice after the discussion had taken place”. Brandt felt this “didn’t feel like the leadership role he imagined the Steering Council would best function in”. Brandt referenced PEP 779, which received engagement from the community but hadn’t received any comments from the Steering Council.

Barry Warsaw, current Steering Council member, said he frequently asks himself, “Am I speaking as a core developer?” Barry referenced how Guido approached discussions and engaged as a core developer, not as a BDFL. Barry identified speaking with consensus as what he thought was the biggest delay, and that it “takes time and coordination”.

Pablo Galindo Salgado, also in the current Steering Council, shared that another issue was that you can’t only participate in discussions that you care about. There’s a scaling issue: “you have to participate in all PEP discussions, and not just to comment, you have to review [the PEP]”. Pablo also highlighted that there’s a problem of engaging with a topic as an individual core developer and then later discussing the topic within the Steering Council, having a different sentiment or reaction, thus causing surprise. “This will happen more if [core developers] expect the Steering Council to participate in discussions, and I am not sure that is going to fly”.

Emily Morehouse, Steering Council member, added that being on the Steering Council is a “seasonal job,” referencing the “onslaught of PEPs submitted ahead of the beta1 cut-off,” which was met with guilty laughter from core developers. Emily suggested being more transparent about a timeline for PEPs would be considered, and when PEPs would need to be submitted to be accepted in time for a particular release.

Mariatta asked about the transparency of funding for the Steering Council. “The Steering Council makes decisions about how the funding is spent, such as PyCon grants and sprints. Are there other ways that the funds can be spent? Can we request grants?”

Emily answered that much of the funding the Steering Council processes had already been “set aside” for specific goals like core developer sprints and the Developers-in-Residence program. Emily shared that “even as a Steering Council member, I want more transparency for [funding]” and that they are “striving for an annual report for how money is being spent”. Some of the funding is a “black box” for the Steering Council as well, so Emily agreed that there should be “more transparency, especially now that there is a substantial amount of money going through the Steering Council budget” and the ability to answer “what happens when we want to use money elsewhere?”

Carol agreed that “more transparency is needed and will solve a lot of the stress” that Steering Council members were feeling.

Guido van Rossum brought up the “Brown Act” in California, which requires that all meetings be open to the public for local government groups in charge of public infrastructure without private deliberations, barring personnel or sensitive issues. “It’s a completely different model” compared to the model set in the Steering Council charter, “but it gives a lot of transparency”. Guido liked the idea of “doing something dramatically different to get the situation unstuck”.

Pradyun Gedam commented on the continuity problem, which the newly proposed Packaging Council, attempted to solve by “splitting the Packaging Council into two cohorts that are elected for two years each, offset by one year”. “This approach might help with some of the [continuity issues]”.

Thomas Wouters said when he was previously on the Steering Council that the members were “always trying to figure out what consensus was”. Thomas’s impression from a previous discussion about Zstandard was “going one way”, but after Gregory Smith ran a poll on Discourse, “the result was very different”. Thomas asked, “Does that mean we have been governing wrong, or should we be doing polls more often?”

Barry replied he thought that “polls are useful, but can’t be relied on completely” as they represented an “incomplete picture of the community”. “There are millions of users that will be affected and aren’t dialed in to Discourse, [the Steering Council] has to represent them, too”.

David Hewitt asked whether a majority of PEPs should be delegated, referencing the typing, packaging, and C API groups that exist already. Emily agreed that more delegation is a “good idea”, but “needed to be formal”. Emily said, “The typing council is a good example of a boundary of responsibility,” but “without a formal decision-making process, we end up with groups that want to help but don’t fulfill their responsibility”. Carol added that historically, most delegations were to individuals rather than working groups or councils.

Pablo also agreed that more delegation was good and that the Steering Council had already been delegating more and seeing success, referencing the typing council, documentation working group, and C API working group. But there are a few problems with the delegation model, like when the “people proposing the changes are a part of the council, so we can’t delegate to [that council].” Pablo also highlighted that delegation was sometimes difficult when there were two opposed groups on an issue. Pablo concluded by saying that “the more working groups we have, the better, but [the Steering Council] can’t demand a working group, so if you want to organize more, please do!”

Emily highlighted more issues with delegation, saying that “we have seen a lot of competing areas that people are working on”. “We’re trying to see how all of these projects work together. [The Steering Council] can’t delegate one person to be the BDFL of the JIT because they will be looking at the JIT but actually need to be looking at many other projects”.


“We’re in a territory that the Steering Council hasn’t had to deal with in a while”, Emily continued, suggesting that the Steering Council needed to contact folks involved in other large decisions in the Python language, such as the 2 to 3 transition.


The Python Language Summit 2025: What do core developers want from Rust?

What do Python core developers want from future Rust support?

“This talk is very timely, Rust turns 10 years old tomorrow”. David Hewitt is the maintainer of PyO3, a library that allows Python developers to more easily use Rust within a Python project. “It takes time for languages to be adopted, the test is whether a decade later the language is used”. David noted that Rust had already been mentioned multiple times earlier in the Language Summit, but also in “the Python Software Foundation’s RFI response to the US government about memory safety” regarding creating binary extensions.

“My belief is we’re all here to enable other developers, and we’re passionate about the tools we want to use ourselves,” noting that all opinions are valid today, whether folks want to use Rust or not.

David showed a graph of which languages are being used by packages on the Python Package Index (PyPI) with C, C++, Rust, and others. “Our best estimate is that somewhere between ¼ and ⅓ of all native code being uploaded to PyPI for new projects uses Rust”. “People are choosing to start new projects using Rust”.

David continued by sharing that PyO3 enables Python users to use Rust in their Python packages. He gave a short demonstration of how PyO3 can be used to create a simple Python module and function, and using Rust error handling in a way that maps directly to Python exceptions. PyO3 has its own build system in Maturin, is capable of generating type hints, and has many more developer-friendly features.

Where do Rust and Python need more work? Rust already “leans very well into supporting free-threading in Python”, but “sub-interpreters and module isolation are a challenge”. Rust has a “GCC backend” if you need to support “esoteric platforms”, but David conceded that “[GCC support] is not very mature yet, one for the future for sure”.

Should Python core developers invest in Rust?

The main question that David came to the Language Summit with is in the title of the talk. “What do Python core developers want from the future of Rust support?” David broke the question down, asking whether core developers “wanted to design or endorse a Rust developer experience” for Python or if the core developers had an interest in Rust for their own toolkit.

Quoting the StackOverflow surveys, Rust is a “very well-loved language” and Rust developers “want to continue working with the language”. Anecdotally, David also shared that “many younger programmers are getting their start with Rust,” which could “increase the size of the talent pool” if Rust were invested in. David also suggested a “higher-level API” compared to the C API written in Rust, which could be a part of the “evolving the C API” to avoid the issues of backwards compatibility.

There are downsides too, David noted that going from one to two languages is a “massive step up in terms of complexity, both technical and social”. “There will probably be something better in the future, so why use it now?” David shared that “some folks believe Rust is ‘good-enough’ for what they need now, so they proceed”. Due to the current state of GCC support, “Rust would alienate esoteric platforms and that would be a shame”. David closed the downsides section with a note on naming: “CPython is ‘C + Python’, what does the C mean if there is Rust investment?”

David closed his presentation with a case study to look at for the adoption of Rust by a prominent C open source project: the Linux kernel. “Rust for Linux is a massively complicated project” and “[the project] is difficult not only technically but also socially” noting that some Linux kernel developers were pushing back against Rust for Linux either because they “don’t want to engage with Rust” or “don’t want their workflows to change”. Despite this, “Rust has been strategically valuable for the Linux kernel because the perception is that it enables a new generation of developers to continue contributing to the Linux kernel”.

Finally, David posed the question, “Is there a world for something like ‘Rust for Python’”?

Discussion 

Fred Drake asked whether David “had done any work with free-threading”? David replied that “working with Rust makes it easy to comply with free-threading,” adding that “you’d have to be using the unsafe keyword or trying really hard” to break Python free-threading with Rust. Marking Rust extension modules as “safe for free-threading” is “a lot more straightforward compared to C”. David thanked the folks at Quansight Labs for their help on PyO3 in this area.

Martin DeMello asked about David’s examples, such as modularizing parts of the interpreter to Rust, and whether David “had tried creating a proof-of-concept?” David replied that he hadn’t tried linking a Rust object into the interpreter but “knows of mixed language projects like Firefox where Rust, C, and C++ are statically linked into the same binary”. David said it’s possible to do, but would be a “high-complexity prototype”.

Brandt Bucher, one of the contributors to CPython’s new JIT suggested that because the JIT is experimental and doesn’t use the CPython API that it may be an interesting candidate for being converted to Rust as a proof-of-concept although Brandt was clear he “wasn’t willing to do the work”.

Gregory Smith suggested starting with an extension module, as they are isolated. “We want a better build system, and we keep talking about it, but [a new build system] hasn’t manifested. It’s all about who is the one doing the work”. Thomas Wouters cautioned that non-optional parts of the standard library would be tough as they “would need to support all tiered platforms”. David agreed, saying that the “build system doesn’t have to happen first” and that the extension module approach was “analogous to the Rust for Linux project,” where certain areas of the kernel were moved to Rust first.

Barry Warsaw asked about the debuggability of Rust if it were adopted in CPython. David replied that the experience wouldn’t be much different. “Rust is creating native call stacks” and “you would see frames in the interpreter, in GDB you would see Rust symbols”.

Hood Chatham had concerns about bloat from panic and symbols for Rust objects being linked to the interpreter. David recommended turning off panic and disabling the Rust standard library, and that there were other ways to avoid bloat that the interpreter didn’t need. “Rust stable ABI is still in progress”.

Overall, after the discussion, core developers did not seem categorically opposed to an optional Rust extension module in the Python standard library, but the general consensus was that this work may hinge on some build system changes and questions around platform support.

 

The Python Language Summit 2025: Updates from the Python Docs Editorial Board

Core developer and Python Docs Editorial Board member Mariatta presented an update on the Python Docs Editorial Board to the Language Summit. Mariatta credited her fellow board members Carol Willing, Guido van Rossum, Joanna Jablonski, and Ned Batchelder for putting together the presentation.

Mariatta started with the mission and vision of the Python Docs Editorial Board, including improving the quality of the Python documentation, getting consensus, and being the final decision makers for documentation issues. Mariatta pointed to the editorial board’s website, which hosts meeting minutes and a “changelog” of decisions.

Mariatta highlighted a few recent decisions, including using the vertical bar (“|”) instead of “or” when describing type information in function parameters and the use of “timezone” versus “time zone” in prose. Ned Batchelder is working on the developer guide, which will “eventually become the new contributors guide for Python”. The group is also modernizing Python tutorials, and Joanna Jablonski and Savannah Bailey are auditing the argparse module documentation.

Mariatta shared that the vision of the Docs Editorial Board is to change Python documentation into a community resource. They hope to do this by making decisions to encourage new contributors and by reducing instances of an individual claiming ownership of a document. The board shared they are “seeing improvement” on this front.

Mariatta celebrated that the board was seeing more collaboration among different groups, such as a renewed emphasis on translations and usability of the documentation. Folks from the Python Software Foundation Education and Outreach Working Group have come to the documentation Discord asking questions and offering help.

Discussion

A short, rapid-fire discussion broke out amongst core developers about the sometimes unfortunate state of pages on the “python.org” subdomain, such as a multitude of wikis. Thomas Wouters and Ned Deily remarked on the previous website revamp and how to avoid breakages, it was “easier to keep pages around, but that doesn’t mean anyone is responsible for the pages”.

Carol Willing, speaking for herself, thought it was “overdue to get rid of links to the wiki, particularly ones that have beginner Python stuff”. PSF executive director Deb Nicholson added that the PSF board was taking a “super macro view of python.org” and to “get in touch with the User Success Working Group if people have questions”.

Python documentation translations were a big topic of conversation during this Language Summit session. Mariatta noted that there were a few language translation groups that were “successful”, giving Korean and Spanish Python docs translations as examples. “We want to learn from groups like that so that even more languages can have that experience”, Mariatta shared, noting that PEP 545, which documents the Python documentation translation guide, focused too heavily on “getting started” rather than “how to continue”.

One of the highlighted issues of PEP 545 was that there would be a single coordinator and no process for adding additional translation coordinators in the case that existing coordinators weren’t available. Mariatta asked the group whether a new governance process, subcommittee, or working group might be able to step in in these situations to “unblock a translation community”.

Lysandros Nikolaou, who has been involved in the Greek translation of the Python docs, highlighted that knowledge-sharing across different translation groups is difficult and a significant barrier to other translations being successful, especially those with smaller communities. “PEP 545 specifies that translations have to have content in the translation language related to the CLA and license,” and this requirement “makes it very difficult for different communities to interact with each other and share knowledge”.

Lysandros shared how the Greek translation group started by “going to the Spanish translation repository and then translating [their processes] from Spanish to English to know what to do”. Lysandros argued that having only one translation coordinator shouldn’t be allowed, and that it’s “difficult enough working on a translation project let alone just one person working on [the translation project]” and that many teams that work on translations know “very little about how to do [process] documentation”. Lysandros agreed that bringing together coordinators would be helpful to every translation.

Donghee Na suggested standardizing on the translation platform across translation groups so that each group can focus their energy on the translation instead of “focusing energy on redoing the same work over and over”.

The Python Language Summit 2025: Packaging Governance Process (PEP 772)

PEP 772 proposes a Packaging Governance Process through a new Python Packaging Council of 5 members (similar to the Python Steering Council). The entire project is a collaboration between Barry Warsaw, Pradyun Gedam, and Python Software Foundation Executive Director Deb Nicholson.

“Packaging is critical to Python’s success”, Barry opened, “Python has grown from a grassroots effort and now needs some formalization; now is the time for Packaging”. Barry explained that the Packaging Governance effort has grown out of the WheelNext initiative. Wheelnext touches many aspects of Python packaging, including installers, the wheel archive format, the Python Package Index, and CPython.

The Packaging Council was modeled after PEP 13 and the Python Steering Council, with a mandate for packaging standards and packaging.python.org. Authority would be given through the Python Steering Council, similar to how the Steering Council delegates packaging PEP decisions today.

There are still some open questions that were likely discussed in more detail at the Packaging Summit, also at PyCon US 2025. Barry enumerated a few issues the group was concerned with, such as how to seed the initial voting membership to form the first Packaging Council, whether to use Python Packaging Authority members, the PSF Packaging Working Group, core developer members, or likely some combination of multiple groups interested in Python packaging.

Barry shared that the Council would likely be in regular communication with the Steering Council but was weighing their options on how to best do updates to the community, either using discuss.python.org, Discord, or some other method. Also suggested was being able to share some staffing resources with the Steering Council, such as the Developers-in-Residence.

Pradyun added to the motivation for a Packaging Council, such as there only being “one standing delegate” for packaging PEPs. Pradyun also added that Python packaging is difficult to reason about, “the various pieces are all over, and you need to know everything to make things happen”.

Deb Nicholson shared that the Python Software Foundation gets contacted about packaging and improvements. “We have funding for packaging work, but we don’t have an entity to ask”. What the PSF wants is a group like the Python Steering Council functions, takes the community temperature, and knows who is interested and whether that entity can work with that PSF so that ideas can get all the way across the finish line”.

Barry clarified that the Packaging Council isn’t going to mandate what third-party tools have to do. The council intends to foster standards for interoperability while “still allowing lots of room for innovation and new ideas”. “Backwards compatibility is one of the axioms of Python packaging,” noted Barry and Pradyun agreed, saying that 12-year-old Python packages “still work” with current tools.

Thomas Wouters asked what Paul Moore, the standing delegate for packaging PEPs, thought of the packaging council PEP. Pradyun responded that “Paul likes the idea”. Deb shared that she had spoken with Paul “at length” and that some of the same problems are being felt with packaging as with Python and the Steering Council. “The amount of work to do compared to 5 years ago has increased 100 times over”. The three had been speaking to many others who have done packaging governance and conducting interviews. Most importantly, “people who have put in the work get to weigh in on PEP 772”.


The Python Language Summit 2025: Python on Mobile - Next Steps

Russell Keith-Magee and Malcolm Smith were at the Language Summit this year to announce the status of mobile support for Python: “After many years, this year I can say that [Python on mobile] is there!” Russell proudly declared, with a large round of applause from the room.

All of the changes for PEP 730 and PEP 738 have been completed, and for Python 3.13, both iOS and Android are Tier 3 supported platforms. Continuous Integration (CI) is very stable, and failures are not because of iOS or Android.

Russell and Malcolm both wanted to know what was necessary for Tier 2 support for iOS and Android. Tier 2 support means that releases are blocked when there are failures for the listed platforms, and that any breakages on those platforms during normal Python development would either need to be fixed or reverted within 24 hours of being detected by build bots.

The platforms both had the requisite 2 maintainers and stable continuous integration via buildbots. The only outstanding question was about whether official “artifacts” or “binaries” are needed for Tier 2 support, which Ned Deily dismissed, stating that “Linux is Tier 1 and doesn’t provide binary artifacts”. Knowing this, Russell and Malcom will proceed with requesting Tier 2 support for iOS and Android.

Russell asked if iOS and Android tests could be added to the GitHub Actions CI that runs on every pull request, making failures more visible (compared to buildbots, which must be explicitly requested). Russell noted that these test runs would not affect CI times due to being shorter than an existing job: the Windows x86-64 free-threaded GitHub Action. The only downside? Running iOS would require macOS ARM runners, which are “in short supply”. Ee Durbin, Director of Infrastructure at the Python Software Foundation, was able to purchase more macOS ARM runners shortly after this issue was identified.

Russell also requested a single-process GitHub Actions run using a Linux runner to catch common issues that fail on mobile, like test cases not being annotated properly as using subprocesses. Thomas Wouters agreed with the proposal to add a single-process test run, noting that this configuration “actually captures bugs” and makes it “easier for the pull request owner to fix issues”.

As far as Python packages go, the Beeware team has made progress; pip and PyPI both support iOS and Android wheels. The build tool Meson is adding support for iOS, and Malcom Smith is adding support for Android. Commonly used tools like “cibuildwheel” would require pre-compiled binaries in order to build mobile-friendly wheels, and “ideally these would be official CPython builds”. The team plans to work on more high-profile packages, like cryptography, to create mobile-friendly wheels.

The Beeware team is maintaining more Apple platforms than only iOS, such as the Apple tvOS, watchOS, and visionOS platforms. Each of these platforms has its own set of patches. Russell asked whether each of these platforms that are quite similar to each other needed their own Tier 3 status for the patches to be upstreamed to Python.

Russell then asked whether the top-level platform directories can be backported to previous versions of Python to accommodate the single XCode project for all platforms proposal. Thomas Wouters, release manager for Python 3.13 and 3.12, was happy to accept backported platform directories as they were unlikely to break many users. Ned Deily agreed and noted that “[he’d] like to get rid of everything in the Mac directory”.

The final question was regarding sysconfig data for mobile builds. Russell noted that mobile binaries are relocatable, but sysconfig data isn’t inherently relocatable and that this is “not just a mobile issue, also affects desktop relocatable and macOS framework builds”. Thomas chimed in again to say that sysconfig data was a “huge problem and not just for [mobile] because it’s tied to the build system”. “We should do something else and get rid of sysconfig data,” which received multiple claps and agreement amongst core developers.

Overall, the mobile story for Python is shaping up nicely, and after the Language Summit talk will likely be even more stable throughout the Python development process thanks to improvements in continuous integration and testing.


The Python Language Summit 2025: Lightning Talks

In memoriam: Michael Foord

Larry Hastings led a moment of silence to remember former core developer Michael Foord, who passed away earlier this year. Michael was known for many things, including “starting the tradition of having the Language Summit events at PyCon”. You can read the memorial for Michael Foord on discuss.python.org.

Pluggable JITs

The first lightning talk was delivered by Martin DeMello from Meta. Martin works on the Cinder Just-in-Time compiler (JIT) at Meta which is “one of two Python JITs”. Martin asks whether there is room for alternative or “pluggable” JITs and envisions a future where a JIT would be pip-installable, a-la “pip install jit”.

To be able to build pluggable JITs, the CPython project would need to provide three things:

  • PyAPI_UnstableFunc()
  • PyEval_EvalFrameJIT()
  • User-defined opcodes

This would avoid the need for other projects like Cinder to copy substantial amounts of CPython code or fork CPython to provide a JIT. JITs need publicly linkable access to low-level functions. Martin has received “pushback” for this sort of API access, but said that “if the social contract is that you have to keep up with language features yourself this would be enough for JIT use”.

Opcodes are a “small namespace” of only 255 values, so “one opcode could be provided for user opcodes and require opargs unpacking” to avoid forking the Python interpreter. The PyEval_EvalFrameJIT() API would be used instead of PyEval_EvalFrame() when a pluggable JIT was used to allow the custom JIT to evaluate frames. See PEP 523 for more information about Python’s current JIT.

Virtual Threads from Java

Mark Shannon asked, “Did Java get threads right?” Mark recently opened a thread on Python Discourse about adding Virtual Threads to Python. Virtual threads are “like green threads” in Java and are built on delimited continuations. Java uses “stackful symmetric” coroutines compared to Python’s “stackless asymmetric coroutines”. Stackful means that code can yield from deep within the call stack, meaning that code avoids the “What color is your function?” problem.

Mark shared a demo that started, briefly ran, and stopped over a million virtual threads, which “if you had been using system threads would have crashed your VM”. Virtual threads are a “bit heavier weight than coroutines”, but might be worth it for the benefits. “Threads don’t scale very well in free-threading”, where if virtual threads are combined with system threads, programs can get better performance. Mark encouraged others to take a look at the proposal on Discourse.

Null Coalescing Operators “??”

Noah Kim proposed adding “null coalescing operators” to Python. Earlier in 2025, Noah opened a thread on discuss.python.org about reviving PEP 505. Instead of “null”, the operators would be “None’-aware. The three operators being proposed are:

  • None-aware access “?.”
  • None-aware comparison “??”
  • None-aware assignment “??=”

Noah shared an example of using each operator. None-aware access is useful for regular expressions to “concisely emulate ‘if is None’ behavior into a single line”:

re.fullmatch(“pat”)?.span() == (0, 6)

Defaults using None can be improved using None-aware comparison and assignment:

headers = headers ?? {“Content-Type”: “application/json”}

headers ??= {“Content-Type”: “application/json”}

Compared to:

if headers is None:

    headers = {“Content-Type”: “application/json”}

Noah shared a potential future for a Python that “builds on none-ness as a core feature”, such as adding .first() and .last() methods to lists when combined with none-aware operators for simpler and more correct code.

Generative AI tooling vibe check

Gregory Smith wanted to get a general vibe-check on AI auto-completion use within an integrated development environment to work on open source software. A rough count of hands in the room showed around half of the folks had used AI autocompletion, and between a third and a quarter of people had used “agentic” AI for open source work. 

“CPython is a very old codebase,” and some modules are “ridiculous for humans to understand,” like the Unicode module. Greg recommended core developers to try out some of the new tools and said, “The upcoming year will be intense in terms of what can be done with the tools”.

Carol Willing shared that she had used and paid for a tool called “CodeVis”. Despite being “early days”, the tool lets you ask questions about a codebase. “Good for exploring codebases you don’t know”. Greg agreed, saying that the tools “can tell you where to go to make changes”. “None of us understand the entire [CPython] codebase. These tools are helpful when plugging into another place you’re not used to”.

Greg is “coordinating with the Python Software Foundation” on making these AI tools available for interested core developers.

Is “worse is better” still better?

The creator of the Python programming language, Guido van Rossum, was next up and asked, “Is ‘worse is better’ still better”? Guido conceded that this was “more a rant than a proposal” to “get core developers thinking”. Guido started by recounting earlier periods of Python development from 35 years ago, where he used UNIX “almost exclusively” and thus “Python was greatly influenced by UNIX’s ‘worse is better’ philosophy”.

“For Python, ‘worse is better’ has served me really well for a long time”, especially when Guido was writing most of the code. Guido shared many of the ways that early Python versions were “worse” than what we have today, such as no long integers, being built on top of C stdio, not having classes, etc.

These limitations meant that Guido could “get something working in 3 months”. “Even in the language definition, I didn’t think hard about many design issues, I copied what I found in C and ABC, Python’s predecessor”.

“Over the years, every single thing where I took a shortcut was eventually fixed”. Dictionary hashing had been “rewritten twice”, “we have garbage collectors up the wazoo”, and “now we have a lot of tests. At the time we had no tests” shared Guido with chuckles from core developers.

“In those times, ‘worse is better’ was key to getting the language accepted. I couldn’t afford to work 3 years on language design without user feedback or endorphins from people giving me kudos”. The initial release of Python happened less than a year after its development began, and “none of the issues were fixed, except classes,” which “were added by an intern”.

“The fact that [Python] wasn’t perfect encouraged many people to start contributing. All of the code was straightforward, there were no thoughts of optimization”. “These early contributors also now had a stake in the language; [Python] was also their baby”. Guido shared that many of these contributors began advocating for Python within their individual places of work.

“Does ‘worse is better’ still have a role today?” Guido contrasted early development to how Python is developed now: “features that take years to produce from teams of software developers paid by big tech companies. The static type system requires an academic-level understanding of esoteric type system features.” And this isn’t just Python the language, “third-party projects like numpy are maintained by folks who are paid full-time to do so”.

“Now we have a huge community, but very few people, relatively speaking, are contributing meaningfully.” Guido asked whether the expectation for Python contributors going forward would be that “you had to write a perfect PEP or create a perfect prototype that can be turned into production-ready code?” Guido opined for the “old days” where feature development could skip performance or feature-completion to get something into the hands of the community to “start kicking the tires”.

“Do we have to abandon ‘worse is better’ as a philosophy and try to make everything as perfect as possible?” Guido thought doing so “would be a shame”, but that he “wasn’t sure how to change it”, acknowledging that core developers wouldn’t want to create features and then break users with future releases.

Guido referenced David Hewitt’s PyO3 talk about Rust and Python, and that development “was using worse is better,” where there is a core feature set that works, and plenty of work to be done and open questions. “That sounds a lot more fun than working on core CPython”, Guido paused, “...not that I’d ever personally learn Rust. Maybe I should give it a try after,” which garnered laughter from core developers.

“Maybe we should do more of that: allowing contributors in the community to have a stake and care”.

Let’s benchmark memory as well

Pablo Galindo Salgado, who is the maintainer of the Python profiler Memray, asserts that CPython should “also benchmark memory”. Execution speeds like “10% faster”, “dominate benchmarks”, but memory is “kinda important as well, especially because we’re doing big changes” and “[Python] is flying blind right now”.

“We’re measuring resident size of memory,” which is kinda like “one eye is blind”. Resident memory doesn’t show when the actual allocation is happening. Pablo also showed that resident memory can be affected by other programs running on your computer. For example, Pablo’s MacBook would non-deterministically move a large allocation of memory to “swap” after sleeping for long periods of time, and this would affect the resident memory graph.

Pablo shared other views into memory available on Linux, such as “working set memory”, showing the memory that your program is “touching”, and showing memory that is allocated but not being used. “Currently, we can’t use these types of memory, we only have one number, [resident memory] today”.

“Memory has become an afterthought, we are focusing too much on speed. Regressions in memory are usually accidental”. Pablo proposed memory.python.org or reusing performance infrastructure, and for the Python core developer team to create some memory-focused benchmarks.

T-strings brain dump

Lysandros Nikolaou gave “less a lightning talk” and “more a brain dump”. Lysandros showed off T-strings (PEP 750) and shared that an issue was opened asking to make Templates and Interpolation types Generic. Lysandros wondered if this was the correct approach or whether core developers needed to “think about the type system in general in a different way”. He didn’t think “any of the choices presented are good enough” for “people building DSLs or combining static analysis and parsing DSLs with runtime information on types”.

Lysandros closed by asking core developers to “think about how the type system will evolve under the unique possibilities that T-strings allow or whether the status quo is enough”.