Python Software Foundation News

Announcing Python Software Foundation Fellow Members for Q3 2025! 🎉

2025-10-22T11:35:00.001-04:00

The PSF is pleased to announce its third batch of PSF Fellows for 2025! Let us welcome the new PSF Fellows for Q3! The following people continue to do amazing things for the Python community:

Abhijeet Mote

Abigail Afi Gbadago

LinkedIn, Website

Becky Smith

LinkedIn, Bluesky, Mastodon, GitHub

Christopher Bailey

Dawn Wages

Leah Wasser

Website, Bluesky, Mastodon, LinkedIn, GitHub

Maaya Ishida

Mason Egger

Website, Twitter, LinkedIn, GitHub

Miguel Grinberg

Website, GitHub

William Vincent

Website, LinkedIn, GitHub

Thank you for your continued contributions. We have added you to our Fellows Roster.

The above members help support the Python ecosystem by being phenomenal leaders, sustaining the growth of the Python scientific community, maintaining virtual Python communities, maintaining Python libraries, creating educational material, organizing Python events and conferences, starting Python communities in local regions, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available on our PSF Fellow Membership page. If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at python.org. Quarter 4 nominations will be in review soon. We are accepting nominations for Quarter 4 of 2025 through November 20th, 2025.

Are you a PSF Fellow and want to help the Work Group review nominations? Contact us at psf-fellow at python.org.

CPython Core Dev Sprint 2025 at Arm Cambridge: The biggest one yet

2025-10-20T12:39:00.000-04:00

Guest blog post authored by Diego Russo, Python Core Developer and Principal Software Engineer at Arm.

Sprint overview

For one week, Arm’s Cambridge headquarters became the heart of Python development. Contributors from around the world came together for the CPython Core Developer Sprint. It was the largest gathering in the project’s history, with 35 core developers and 13 invited guests collaborating in person.

Unlike a conference, the sprint is a working retreat. There are no spectators or formal keynotes, just space for deep technical debate, design, coding, and consensus-building.

The sprint offers a rare chance for real-time dialogue. Ideas can be sketched on whiteboards, trade-offs debated face-to-face, and tricky issues given momentum.

What happened

The week included technical presentations, collaborative work, and community events. Talks and presentations were grouped around key themes:

JIT and performance

Ken Jin Ooi – Building a Community Around the JIT Compiler and demo of the new C API
Antonio Cuni – Tracing JITs in the Real World, highlighting challenges such as trace blockers, control flow, and async behavior

Packaging and distribution

Russell Keith-Magee – Managing Cross-Platform Wheel Builds
Brett Cannon – Precompiled Binaries from python.org

Language design and standards

Steering Council – PEP 793 and abi3/abi3t/abi4
Matthew Parkinson – Designing Deep Immutability

Ecosystem and infrastructure

Brett Cannon – WASI Update
Hood Chatham – Upstreaming the Pyodide FFI
Gregory P. Smith – Claude Code and Agents for Good in OSS

Lightning talks

Guido van Rossum – A New Python History Project
Ee Durbin – PSF Infrastructure Next Gen
Steve Dower – Python Install Manager
Larry Hastings – A Missing Fundamental Data Structure
Adam Turner – Bring Out Yer Dead (Issues)
Greg Smith – Async Exception Group Tracebacks

Arm contributions

James Greenhalgh – Arm Neoverse: Overview
Martin Weidmann – A Brief History of the Arm Architecture
Peter Smith – Compilers, ABI, and Optimizations

The program also included a Q&A with the Steering Council, where Barry Warsaw and Emily Morehouse joined remotely. It also featured a mentorship discussion led by Tania Allard on how to welcome and support new contributors.

Beyond presentations, the sprint fostered hands-on collaboration. Developers had advanced JIT planning, explored progress on free threading, and discussed improvements to documentation and translations. They also strengthened testing and CI across platforms, and refined governance and contributor onboarding processes.

Antonio Cuni highlighted real-world JIT pitfalls, which informed many of these discussions.

Finally, the sprint included community activities that helped balance the technical intensity with moments of connection. The Python Guild at Arm hosted an Ask Me Anything (AMA) session, giving local engineers the chance to interact with core developers.

A formal dinner at Jesus College reflected Cambridge traditions, while a punting trip on the River Cam offered a relaxed opportunity to connect outside of work.

A Team Effort

The Python Software Foundation coordinated the event, making the sprint possible. We thank Phyllis Dobbs for managing the RSVP process and the travel grants that enabled many contributors to join us in Cambridge.

Hosting the CPython Sprint at Arm’s Cambridge offices shows a shared commitment and we send huge thanks to everyone at Arm who made the sprint possible. Arm shares,

“Hosting the latest CPython sprint was more than providing a venue. It was an investment in strengthening one of the most influential open-source communities. Python’s reach is vast, and ensuring its modern components run smoothly on Arm platforms helps the language stay inclusive and performant across architectures. Hosting the sprint gave Arm a way to give back, reinforce bonds with the core team, and invest in Python’s future.”

The Arm Software Communities team led the effort from start to finish, handling logistics, sponsorship, and every detail that kept things running smoothly. Their support, along with the help of Central Engineering, Facilities, Workplace, People, IT, Developer Marketing, and the Python Guild organizers, ensured a successful and well-organized week for all participants.

Finally, a huge thank you to all the attendees who traveled from across the world to spend a week in Cambridge. Some came from nearby in the UK and neighboring countries. Many others journeyed across Europe, several crossed the Atlantic, and a few took long-haul and even ultra-long-haul flights of more than 10,000 km. That dedication and commitment to the Python community is what truly made this sprint special.

Organizing a sprint of this scale takes many hands. From sponsors to volunteers, organizers to attendees, everyone contributed in their own way. This sprint was a reminder that Python is more than a programming language. It is a community that works together, supports one another, and achieves more as a team than any individual could alone.

Conclusion

The sprint was widely regarded as a success. Attendees described it as productive, well-organized, and an excellent community experience. Even so, some aspects could have been improved, and these are valuable lessons to take forward for future events.
Sessions such as the Steering Council Q&A, the mentorship discussion led by Tania Allard, and the lightning talks stood out as highlights. They reinforced the value of bringing the community together in person.

Python is undergoing important technical transitions. Sprints like this accelerate evolution, resolve difficult challenges, and align the community. The concentration of expertise enabled focused, collaborative progress. The ripple effects of this sprint will shape code, discussion, and design decisions for months to come. We look forward to coming together again as a community.

Announcing PSF Community Service Award Recipients!

2025-10-15T09:52:00.000-04:00

The PSF Community Service Awards (CSA’s) are a formal way for the PSF Board of Directors to offer recognition of work which, in its opinion, significantly improves the Foundation's fulfillment of its mission and benefits the broader Python community. These awards shine a light on the incredible people who are the heart and soul of our community– those whose dedication, creativity, and generosity help the PSF fulfill its mission. The PSF CSAs celebrate individuals who have been truly invaluable, inspiring others through their example, and demonstrates that service to the Python community leads to recognition and reward. If you know of someone in the Python community deserving of a PSF CSA award, please submit them to the PSF Board via psf@python.org at any time. You can read more about PSF CSAs on our website.

The PSF Board is excited to announce three new CSAs, awarded to Katie McLaughlin, Sarah Kuchinsky, and Rodrigo Girão Serrão, for their contributions to the Python community. Read more about their contributions and impact below.

Katie McLaughlin

Katie has been a tireless and dedicated member of the Python and Django communities for many years. They have served on the boards of both the DSF and PSF, including as PSF Communications Officer, and was named a PSF Fellow in 2018. Katie has played a big role in the Australian conference community– chairing DjangoCon AU 2017, PyCon AU in 2018 and 2019, and co-chairing PyCon AU 2021– and continues to support PyCon AU as an advisor.

A frequent speaker and keynote presenter at PyCons and DjangoCons around the world, Katie has worked to demystify Python website deployment, highlight the value of all kinds of open source contributions, and call out the impact of contempt culture on developer communities. They are also a regular at sprints, helping new contributors get started and improving onboarding through code and documentation.

Sarah Kuchinsky

Sarah has been the driving force behind PyCon tutorials for many years, shaping them into the strong program they are today. She has brought skill, care, and consistency to the difficult work of selecting, organizing, and running tutorials, ensuring they provide meaningful learning experiences for attendees.

Beyond logistics, Sarah has a gift for spotting and nurturing talent. She has encouraged new volunteers to grow into leadership roles, building a resilient, collaborative committee that sustains itself year after year. Her outreach has kept reviewers engaged while also welcoming fresh voices, strengthening both the program and the community behind it.

The impact of Sarah’s work is felt by every instructor, attendee, and volunteer who has benefitted from PyCon tutorials, and the community is deeply grateful for her many years of leadership and care. Sarah was also the lead organizer for PyLadies Silicon Valley for over 5 years, is a SoCal Python Co-Organizer, and has contributed to a variety of open source projects.

Rodrigo Girão Serrão

Rodrigo Girão Serrão has made lasting contributions to the international Python community through his leadership, teaching, and generosity. He has helped organize PyCons in Portugal, supported the Python community across Europe, and spoken regularly at PyCons worldwide, making complex topics like descriptors clear and approachable.

Through his website mathspp.com, bootcamps, and self-published books, including the freely available Pydon’ts book, Rodrigo has worked to make Python more accessible and welcoming. His dedication to sharing knowledge and supporting others has had a wide-reaching impact, and the community is grateful for his many contributions.

Announcing the 2025 PSF Board Election Results!

2025-09-16T13:11:00.000-04:00

The 2025 election for the PSF Board created an opportunity for conversations about the PSF's work to serve the global Python community. We appreciate community members' perspectives, passion, and engagement in the election process this year.

We want to send a big thanks to everyone who ran and was willing to serve on the PSF Board. Even if you were not elected, we appreciate all the time and effort you put into thinking about how to improve the PSF and represent the parts of the community you participate in. We hope that you will continue to think about these issues, share your ideas, and join a PSF Work Group or PSF initiative if you feel called to do so.

Board Members Elect

Congratulations to our two new and two returning Board members who have been elected!

Abigail Dogbe
Jannis Leidel
Sheena O’Connell
Simon Willison

We’ll be in touch with all the elected candidates shortly to schedule onboarding. Newly elected PSF Board members are provided orientation for their service and will be joining the upcoming board meeting.

Thank you!

We’d like to take this opportunity to thank our outgoing board members. Kushal Das has been serving on the PSF Board for over ten years– WOW! Kushal has been a part of change after change for the PSF and Python community, serving in PSF Board officer positions, and we are incredibly grateful for his contributions. Dawn Wages quickly became an integral part of the Board during her tenure, stepping up as Treasurer and then Board Chair. Dawn helped guide us through a period of major change– navigating a difficult economy, adapting to the rise of AI, and supporting important shifts in our programs. Thank you, Kushal and Dawn, for your leadership and dedication to the PSF and the Python community. You will be missed and are deeply appreciated!

Our heartfelt thanks go out to each of you who took the time to review the candidates and submit your votes. Your participation helps the PSF represent our community. We received 683 total ballots, easily reaching quorum–1/3 of affirmed voting members (929). We’re especially grateful for your patience with continuing to navigate the changes to the election processes and schedule, which allows for a valid election and a more sustainable election system.

We also want to thank everyone who helped promote this year’s board election, especially Board Members Cristián Maureira-Fredes and Georgi Ker, who took the initiative to cover this year’s election and produced informational videos for our candidates. This promotional effort was inspired by the work of Python Community News in 2023. We also want to highlight the PSF staff members and PSF Board members who put in tons of effort each year as we work to continually improve the PSF elections.

What’s next?

If you’re interested in the complete tally, make sure to check the Python Software Foundation Board of Directors Election 2025 Results page. These results will be available until Nov 11, 2025.

The PSF Election team will conduct a retrospective of this year’s election process to ensure we are improving year over year. We received valuable feedback about the process and tooling. We hope to be able to implement more changes for next year to ensure a smooth and accessible election process for everyone in our community.

Finally, it might feel a little early to mention this, but we will have at least 3 seats open again next year. If you're interested in running or learning more, we encourage you to contact a current PSF Board member or two this year and ask them about their experience serving on the board.

Sprints are the best part of a conference

2025-09-10T06:30:00.002-04:00

When I first started attending Python conferences, my focus was entirely on the talks on the schedule. That's not surprising, there's no conference without talks! Over the years, though, I came to appreciate the so-called hallway track and the usual post-conference sprints that many events include. These days, I mostly come for those. Let's talk about why.

Raw numbers

Before we get into subjective and soft reasons why sprints are great, just consider how productive they are for Python. To give you an idea, let's focus on three Python conferences of different sizes on three continents.

At PyCon US 2025, 370 new PRs were open to the Python organization during, 286 to the cpython repository alone. Close to 300 PRs were merged into the Python GitHub organization during that time. That's for four days of sprints. This is over 2X the number of PRs handled during the same period when there's no sprint happening.

There's been two days of sprints at EuroPython in Prague this year, but they didn't disappoint either: 122 new PRs open to the Python organization, including 99 to the cpython repository. 79 PRs were merged into the Python GitHub organization during this time. This is 1.75X the number of PRs handled during a typical weekend.

Even single-day sprint days at conferences are pretty productive. At PyCon Korea earlier this August the attendees managed to open 59 new PRs to the Python organization, including 35 PRs to the cpython repository. Over 40 PRs were merged into the Python organization that day. Still 1.7X the typical velocity.

Hopefully, you're seeing what I'm seeing: sprints can provide a measurable boost to an open-source project. The longer the sprints are, the bigger this boost is. This is because many contributions need more than a day to bake, some bugs can be pretty stubborn, and many features uncover surprising depth once you start implementing them.

Momentum

There's something magical about a large group of people banding together to attack problems. While this is what open source is in general, adding together physical presence in the same physical space at the same time is the secret sauce. Real-time coordination really is more efficient. We can guess at reasons for this, but we can safely assume a big part is simply that humans are social animals. It's easier to empathize with a person when they're in the same room with you. In my experience, pointing at a screen still beats Internet communication.

Part of what makes sprints so productive is that it is a time-boxed period of uninterrupted time away from your usual work environment. And that's true for everyone, so people have the ability to focus on a specific project or problem for an extended period of time. But since there's a time limit to how long the sprints are, there's also some productive pressure to ship something concrete by the end of your stay. So, it's rare to see people playing games or doomscrolling during sprints. Instead, they want to ship something, even if it's a humble small first contribution.

Better yet, after you spend some time with a person in real life, even online interactions with them afterwards change. My brain does this thing where it reads GitHub comments of people I know in their voice. This little thing additionally humanizes the pixels on screen and makes the interaction smoother. When you come to sprints, you build more lasting connections, because you don't only talk about stuff in the hallway, you're solving problems together.

You're getting for free what you wouldn't be able to buy if you tried

You're solving problems together alongside developers from different companies, backgrounds and specialties. Some of them are maintainers of the projects you're contributing to, with a wealth of expertise they're sharing freely. You get immediate feedback, you can learn at a rate that is impossible to match online. You learn not only by doing and asking questions, but even just by watching others work. You discover better tools or ways to use them you didn't know existed.

To put it bluntly, the experts you work with during sprints would be impossible to hire as tutors, and here you get to work with them free of charge. Think about it, that alone makes it worth staying for sprints. And don't get cold feet, either, because...

You belong

I've heard some newcomers are worried that maybe the expected experience level is too high. I say you will definitely find something productive to do. I even blogged about this specifically for PyCon US this year, so you can read "What to Expect at PyCon US Sprints" to get an idea about how to make your experience great. The PyCon Korea sprint organizer and Steering Council member Donghee Na says: "I notice that the participants who had a good experience at last year's sprint tend to rejoin the sprint this year. I hope that many of them come back next year too." I'm seeing the same thing, and want to see even more of it. We do care about your experience.

Specifically at PyCon US, this year we tried something new. We split the CPython sprint room into two rooms: one dedicated to first-time contributors, and one to seasoned developers that needed to focus on some feature or bugfix they really wanted to ship before leaving Pittsburgh. It turned out great. Talking to attendees on both ends, I think both rooms enjoyed this setup and we will be repeating that for next year. While I was coordinating the first-time contributor room, I was heartened to see that quite a few veteran core developers joined me in the room. It was fun all four days!

At EuroPython, the setup this year was such that Petr Viktorin and I were coordinating the CPython sprint... or so we thought! In parallel, Adam Turner was leading the CPython documentation sprint, but attendees responded so well to him that he quickly organically became the de facto leader of the entire CPython sprint. Kudos, Adam, you did great!

Dedicated sprint events

It's not all roses with sprints that are attached to conferences. After an intense few days of the larger event, people tend to get tired. Introverts run out of steam. Key people that you could use talking to don't stay or are only available on the first day. If only there could be an event where core developers gather for a week just to sprint. No distracting talks and hallway tracks!

CPython actually does this annually since 2016 with the obvious online-only hiccup of 2020 and 2021. We do love those sprints as they are both productive and fun. Last year we returned to Meta while this year we will be sprinting at Arm Ltd in Cambridge UK. Unlike the conference sprints, this is an invite-only event for core developers where we can focus on making the next version of Python shinier than it would otherwise be.

But maybe organizing sprint-first events makes sense in general? It seems to me like that could be pretty helpful. Or maybe this is already a thing? Let us know if you know of sprint-first events in your area.

And in the meantime, consider staying for sprints at the next conference you're attending. It's well worth it!

The 2025 PSF Board Election is Open!

2025-09-02T10:02:00.000-04:00

It’s time to cast your vote! Voting for the 2025 PSF Board Election is open starting today Tuesday, September 2nd, 2:00 pm UTC, through Tuesday, September 16th, 2:00 pm UTC.

How to Vote

If you are a voting member of the PSF who affirmed your intention to participate in this year’s election or you voted in last year’s election, you will receive an email today from “OpaVote Voting Link <noreply@opavote.com>” with a link to your ballot. The subject line will read “Python Software Foundation Board of Directors Election 2025”. If you haven’t seen your ballot by Wednesday, please first check your spam folder for a message from “noreply@opavote.com”. If you can’t find the ballot email from OpaVote please get in touch by emailing psf-elections@pyfound.org so we can look into your account and make sure we have the most up-to-date email for you.

Four seats on the board are open, but you can vote to approve as many of the 13 candidates as you like. We’re delighted by how many of you are willing to contribute to the Python community by serving on the PSF Board! Make sure you take some time to look at all the nominee statements and choose your candidates carefully.

ATTN: Choose carefully before you press the big green vote button. Once your vote is cast, it cannot be changed.

Who can vote?

You need to be a Contributing, Supporting, or Fellow member and have affirmed your voting intention by August 26th, 2:00 pm UTC, to vote in this election. Per last year’s Bylaw change that allows for simplifying the voter affirmation process by treating past voting activity as intent to continue voting, if you voted last year, you have been automatically added to the 2025 voter roll. Please note: If you removed or changed your email on psfmember.org, you may not automatically be added to this year's voter roll.

Reminder that if you were formerly a Managing member, your membership has been updated to Contributing as of June 25th, 2025, per last year’s Bylaw change that merged Managing and Contributing memberships.

If you’d like to learn more or sign up as a PSF Member, check out our membership types. You can check your membership status on your User Information page on psfmember.org (you will need to be logged in). If you have questions about your membership or the election please email psf-elections@pyfound.org

pypistats.org is now operated by the Python Software Foundation

2025-08-26T08:40:00.006-04:00

For a little over six years pypistats.org has been maintained and operated by Christopher Flynn on a volunteer basis. After a recent extended outage made clear the importance of this service to the Python community, and in coordination with Christopher, the Python Software Foundation (PSF) has adopted the project into our GitHub organization and migrated the service to run from our infrastructure.

So what has changed? As far as the day-to-day operations of the service goes the PSF Infrastructure Team will now make sure that pypistats.org’s backing infrastructure, costs, and domain registration are all maintained. Otherwise, there is no material change to the service. The project remains open source and community maintained. We are appreciative that Christopher has stated his intention to stay on as maintainer of the project and we welcome the community to get involved.

We're also grateful to Christopher for his long-term volunteer contribution maintaining this service! As an organization, we are excited to have the opportunity to support pypistats.org and ensure it remains available to the community. Stories like this –under-resourced, but highly depended upon services– are not a new story for the open source community, and we are glad that this story had a positive outcome.

The PSF’s Infrastructure Team is excited to be in a place to adopt services like these into our burgeoning community infrastructure along with services like the PyLadiesCon Portal and memory.python.org. This new community infrastructure, supported by AWS Open Source via their credits program, is backed by the same tooling that delivers pypi.org, python.org, and us.pycon.org along with many other PSF hosted services. We look forward to sharing more in the coming months– not only what we're up to but also how you can get involved!

The 2024 Python Developer Survey Results are here!

2025-08-18T09:06:00.004-04:00

We are excited to share the results of the eighth official annual Python Developers Survey. This survey is done yearly as a collaborative effort between the Python Software Foundation and JetBrains. Check out Michael Kennedy's The State of Python 2025 blog post, on the JetBrains blog, which reflects his personal analysis and opinions on the data. Responses were collected October and November of 2024. More than 30,000 Python developers and enthusiasts from almost 200 countries and regions participated in the survey to reveal the current state of the language and the ecosystem around it.

Check out the survey results!

The survey aims to map the Python landscape and covers the following topics:

General Python usage
Purpose for using Python
Python versions
Frameworks and Libraries
Cloud Platforms
Data science
Development tools
Python packaging
Demographics

We encourage you to check out the methodology and the raw data for this year's Python Developers Survey, as well as those from past years (2023, 2022, 2021, 2020, 2019, 2018, and 2017). We would love to hear about what you learn by digging into the numbers! Share your results and comments with us on social media by mentioning JetBrains (LinkedIn, X) and the PSF (Mastodon, LinkedIn, X) using the #pythondevsurvey hashtag. Based on the feedback we received last year, we made adjustments to the 2024 survey- so we welcome suggestions and feedback that could help us improve again for next year!

Announcing the PSF Board Candidates for 2025!

2025-08-14T12:19:00.000-04:00

What an exciting list! Please take a look at who is running for the PSF Board this year on the 2025 Nominees page. This year there are 4 seats open on the PSF Board. You can see who is currently on the board on the PSF Officers & Directors page. (Dawn Wages, Jannis Leidel, Kushal Das, and Simon Willison are at the end of their current terms.)

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 26th, 2:00 pm UTC
Voting start date: Tuesday, September 2nd, 2:00 pm UTC
Voting end date: Tuesday, September 16th, 2:00 pm UTC

Not sure what UTC is for you locally? Check this time converter!

Reminder to affirm your intention to vote!

If you wish to vote in this year’s election, you must affirm your intention to vote no later than Tuesday, August 26th, 2:00 pm UTC, to participate in this year’s election. This year’s Board Election vote begins Tuesday, September 2nd, 2:00 pm UTC, and closes on Tuesday, September 16th, 2:00 pm UTC.

Every PSF Voting Member (Supporting, Contributing, and Fellow) needs to affirm their membership to vote in this year’s election. You should have received an email from "psf@psfmember.org <Python Software Foundation>" with the subject "[Action Required] Affirm your PSF Membership voting intention for 2025 PSF Board Election" that contains information on how to affirm your voting status.

Find more information, including step-by-step instructions on voting affirmation, in our ‘Affirm Your PSF Membership Voting Status” blog post. If you run into any issues, please email psf-elections@pyfound.org.

Voting: what to expect

If you are a voting member of the PSF that affirmed your intention to participate in this year’s election, you will receive an email from “OpaVote Voting Link <noreply@opavote.com>” with your ballot, the subject line will read “Python Software Foundation Board of Directors Election 2025” on September 2nd. If you don’t receive a ballot as expected, please first check your spam folder for a message from “noreply@opavote.com”. If you don’t see anything get in touch by emailing psf-elections@pyfound.org so we can look into your account and make sure we have the most up-to-date email for you.

If you have questions about your membership status or the election, please email psf-elections@pyfound.org. You are welcome to join the discussion about the 2025 PSF Board election on the Python Discuss forum.

Announcing Python Software Foundation Fellow Members for Q2 2025! 🎉

2025-08-08T08:47:00.000-04:00

The PSF is pleased to announce its second batch of PSF Fellows for 2025! Let us welcome the new PSF Fellows for Q2! The following people continue to do amazing things for the Python community:

Hamdalah Adetunji

Laís Carvalho

Mark Smith

Website, LinkedIn, Mastodon, Bluesky, GitHub

Will McGugan

Blog, X (Twitter), Mastodon, GitHub

Thank you for your continued contributions. We have added you to our Fellows Roster.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available on our PSF Fellow Membership page. If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at python.org. Quarter 3 nominations will be in review soon. We are accepting nominations for Quarter 3 of 2025 through August 20th, 2025.

Are you a PSF Fellow and want to help the Work Group review nominations? Contact us at psf-fellow at python.org.

Unmasking Phantom Dependencies with Software Bill-of-Materials as Ecosystem Neutral Metadata

2025-08-07T08:45:00.001-04:00

The Python Software Foundation Security Developer-in-Residence, Seth Larson, published a new white paper with Alpha-Omega about the work to solve the "Phantom Dependency" problem. The white paper details the approach, challenges, and insights into the creation and acceptance of PEP 770 and adopting Software Bill-of-Materials (SBOMs) to improve the measurability of Python packages.

This work means that automated systems like vulnerability scanners, compliance, and policy tools will provide accurate results, even in complicated software composition and dependency graphs that are common for scientific computing, performance-critical workloads, and artificial intelligence.

Critical projects like numpy, cryptography, and pip are already evaluating adopting PEP 770 and providing cross-ecosystem dependency information through the use of SBOMs.

The Security Developer-in-Residence position is sponsored by Alpha-Omega. If you'd like to support improving Python at the ecosystem-scale contact sponsors@python.org to discuss sponsoring a Developer-in-Residence position.

The PSF has paused our Grants Program

2025-08-05T06:13:00.002-04:00

TL;DR:

Effective August 1st, 2025, the PSF is temporarily pausing our Grants Program after reaching our 2025 grant budget cap earlier than expected. We know how important this program is to many in our community and making this decision was difficult. This is a necessary step to protect both the future of the program and the short- and long-term sustainability of the PSF. (If this moves you immediately to donate to the PSF, we welcome your contributions via our donations page).

The PSF Grants Program is paused

As we shared in December 2024 (specifically, part 3), the PSF implemented changes to the Grants Program in March 2025 in an effort to ensure the sustainability of the program and the foundation. PSF Staff have been checking in quarterly on our award expenditure, and at the end of Q1, we were on track. When PSF Staff reviewed approved grant awards at the end of Q2, however, we had granted close to 80% of the 2025 grant budget. The grant applications received so far through July exceed the budget ceiling.

What does this mean? The PSF Board has voted to implement a pause, effective August 1st, 2025, on the PSF Grants Program. The PSF Board and Staff explored our options thoroughly before coming to this tough, and frankly painful, decision as we deeply understand how important the grants program is to the Python community.

Everyone at the PSF is constantly amazed and impressed with the creativity, drive, and ingenuity of the Python community. Supporting the community’s success with our Grants Program is at the heart of our mission—and it brings so much joy to the PSF Board, our small but mighty team of staff, and the wonderful folks in our Work Groups. We are heartbroken to have to pause that work and we know this will be challenging and create more difficult decisions in turn for the many community groups that had planned to apply for the grants program.

We will be distributing the small amount of remaining funds in the 2025 PSF Grants Program budget. To honor the time and energy spent on applications already submitted and in the spirit of equity, any applications that were received before August 1st, 2025 will be granted a uniform percentage of the award amount for which they are eligible. If you have a grant application in the system, you will receive an email from us soon with more information. Please send any urgent inquiries to grants@python.org.

The PSF aims to be as transparent as possible, and we want to have two-way conversations with the community about this change. We are holding an additional PSF Grants Program Office Hour in August on the PSF Discord. We welcome folks to join both or either session:

August 13th, 8-9 pm UTC
August 19th, 1-2 pm UTC

We also welcome your feedback, particularly how we can support you during this pause, via email to grants@python.org or on the thread we’ve started on discuss.python.org.

How we got here

Since announcing Grants program changes in December 2024, grant requests have grown about 40% over last year. It’s wonderful to see long-time events continue to grow. It’s been equally inspiring to see events being revived as we move further from 2020 and the start of the COVID pandemic, alongside brand-new initiatives from new and seasoned organizers. The PSF loves seeing the growth, but the heart of the issue is that Python and its community continue to grow exponentially, while our funding has not kept pace, and in fact, has decreased.

With Python being the number one language on GitHub and rising steadily on the TIOBE index, it’s no surprise that our community continues to build and grow as well. You can see the TIOBE index shows what the growth of Python looks like over the years, and how much it’s grown in just the past year:

By contrast, the PSF’s available resources have decreased over the last three years and are projected to decrease again in 2025 due to increasing PyCon US and foundation costs. Much of the growth shown before 2022 in the chart below comes from grants we received that were restricted funds dedicated to specific staffing and other programs. The result is increasing global community activity against a decreasing pool of available funds.

For example, 2023 year-end assets were $5.5M with total grants awarded at $677K. The following year, 2024 assets decreased slightly to $4.3M, but grants awarded jumped to $952K. You can see in the graph above how that negatively impacted our assets, a trend that is not sustainable even in the short term. Please check out the PSF’s 2024 Annual Impact Report for more details of our finances and our work.

The PSF Grants Program adjustments implemented earlier this year aimed to reduce total grant award spending while providing a more equitable approach, but the growth in new/revived grant applications outpaced the lowered caps and other limits. As we reviewed Q2 spending, it became clear that the unexpected influx of qualified grant proposals had already almost exhausted the total amount we had budgeted for the full year.

We’re in this together

The PSF is in a similar position to the many other organizations and NGOs (and all of our volunteer conference and meetup organizers!) trying to support the Python community and foundation while faced with inflation, lower sponsorship, economic pressure in the tech sector, and global/local uncertainty and conflict.

Last year, the PyCon US blog explained that PyCon US 2024 generated a significant loss; losses from PyCon US are paid for by PSF general funds that are also the financial source for the PSF Grants programs. For many years, PyCon US created a surplus used to fund Grants, PSF staff, and other programs. Based on the current numbers for PyCon US 2025, the PSF will need to fund another loss. Many factors including the lower-than-budgeted attendance, higher location costs, and the current economic and political situation contributed to the loss despite incredible efforts by staff and volunteers to control costs.

What’s the solution?

In an ideal world, we wouldn’t need to pause the Grants Program and would instead be granting even MORE awards to our inspiring community. And while that’s not currently the case, we do think you can help us unpause the grants program and fund the PSF’s other work. The PSF needs more support and resources from the corporations that are built on and making revenue from Python. As a community, let’s ask corporations to step up and sustain the health of the community and programming language they rely on. The AI sector, for example, relies heavily on Python and is mostly untapped for the PSF, PyCon US, and our entire community. If you have potential sponsorship connections (in AI or otherwise) we welcome you to send us leads or connect us via sponsors@python.org.

The PSF is ever grateful for our sponsors, past and current, and we do everything we can to make their sponsorships beneficial and rewarding. PSF Staff also work hard to make those sponsorship dollars stretch as far as they can. Frankly, the PSF simply needs more sponsorship to continue to support the astonishing growth of Python and its community.

The PSF is also incredibly grateful for our individual donors and PSF members. We truly couldn’t do this without you. If you’re inspired to help because of this post, we urge you to ask your employers to sponsor the PSF. Send them the PSF’s sponsorship page! We know times are financially challenging for everyone, but if you’re feeling very inspired and in a position to donate, we welcome your contributions via the PSF’s donation page. You can also join us as a PSF Supporting Member (a sliding scale is also available!), to invest in the future of Python and its community.

Some additional context

As PSF Staff reviewed the Q2 numbers for the Grants Program, we found the following:

Revived events. 10 out of the 75 (or about 13%) grants applications we’ve received in 2025 are for “revived” grant applications for events that weren’t run in 2024 (including one that hasn’t been run since 2015, whoa!).
Net new applications. 19 out of the 75 (or about 25%) grant applications we’ve received in 2025 are for totally new events and initiatives. While we did expect some growth, this is tremendous!
Earlier applications. We encouraged folks to apply earlier—and you did, thank you! We weren’t expecting this level of awarding by mid-year. We also expect that to continue, so we can now plan better for that in the future.
Higher $$ requests. Across all returning applications the amount being requested is about 13% higher than in years previous.

While we expected more interest from the community in the PSF grants program, the amount of growth far exceeded our expectations.

What’s next?

The PSF is working on our strategy to balance support for the worldwide Python community and funding constraints, now and in the future. The unknown and rapidly growing number of new Python events and initiatives—combined with the ongoing needs of existing events and organizations that have historically relied on the PSF Grants Program—is challenging to manage sustainably on a rolling application basis.

So, here’s our plan:

First, the PSF Board will continue to refine the grant program’s guiding principles and how they translate into program policy.
From there, PSF Staff will research, plan, and implement a quarterly review and awarding approach for the PSF Grants Program to provide an equitable and financially sustainable process.

Moving to a quarterly review process from the rolling approval process the Grants Program currently uses will be a big change! We will do our best to implement processes that work well for the community, the Grants Workgroup, and PSF Staff.

Even with our best efforts, we acknowledge that there will be learning opportunities around moving to a quarterly review and most likely a series of adjustments ahead of us to get things working smoothly. Your feedback as grant applicants and recipients will be extremely helpful as we take on this journey. During this process, we will determine on what timeline we can re-open the Grants Program. You can expect updates from us on the future of the PSF Grants Program in early 2026.

PSF Board Election Nominations Opening July 29th

2025-07-24T09:55:00.003-04:00

This year’s PSF Board Election nomination period opens next week on Tuesday, July 29th, 2:00 pm UTC and closes on Tuesday, August 12th, 2:00 pm UTC. 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.

This year, there are 4 seats open on the PSF Board. Check out who is currently on the PSF Board on our website. (Dawn Wages, Jannis Leidel, Kushal Das, and Simon Willison are at the end of their current terms.) Check out the following resources to learn more about the PSF, as well as what being a part of the PSF Board entails:

Life as Python Software Foundation Director video on YouTube
FAQs About the PSF Board video on YouTube
Our past few Annual Impact Reports:

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 26th, 2:00 pm UTC
Voting start date: Tuesday, September 2nd, 2:00 pm UTC
Voting end date: Tuesday, September 16th, 2:00 pm UTC

Not sure what UTC is for you locally? Check this UTC time converter!

Nomination details

You can nominate yourself or someone else. We encourage you to reach out to people before you nominate them to ensure they are enthusiastic about the potential of joining the Board.

To submit a nomination for yourself or someone else, use the 2025 PSF Board Election Nomination Form on our website. The nomination form opens on Tuesday, July 29th, 2:00 pm UTC and closes on Tuesday, August 12th, 2:00 pm UTC.

To support potential candidates and nominators, the 2025 PSF Board Election team has created a nomination resource (embedded below). It includes tips, formatting instructions, and guidance on what to include in a nomination. The goal is to help nominees understand what to expect and ensure that all candidates are provided the same clear and consistent standards.

Voting Reminder!

Every PSF Voting Member (Supporting, Contributing, and Fellow) needs to affirm their membership to vote in this year’s election. You should have received an email from "psf@psfmember.org <Python Software Foundation>" with the subject "[Action Required] Affirm your PSF Membership voting intention for 2025 PSF Board Election" that contains information on how to affirm your voting status.

You can see your membership record and status on your PSF Member User Information page. If you are a voting-eligible member and do not already have a login, please create an account on psfmember.org first and then email psf-elections@python.org so we can link your membership to your account.

Affirm Your PSF Membership Voting Status

2025-07-16T08:43:00.000-04:00

Every PSF voting-eligible Member (Supporting, Contributing, and Fellow) needs to affirm their membership to vote in this year’s election.

If you wish to vote in this year’s PSF Board election, you must affirm your intention to vote no later than Tuesday, August 26th, 2:00 pm UTC. This year’s Board Election vote begins Tuesday, September 2nd, 2:00 pm UTC, and closes on Tuesday, September 16th, 2:00 pm UTC.

You should have received an email from "psf@psfmember.org <Python Software Foundation>" with the subject "[Action Required] Affirm your PSF Membership voting intention for 2025 PSF Board Election" that contains information on how to affirm your voting status. If you were expecting to receive the email but have not (make sure to check your spam!), please email psf-elections@pyfound.org, and we’ll assist you. Please note: If you opted out of emails related to your membership, you did not receive this email.

Need to check your membership status?

Log on to psfmember.org and visit your PSF Member User Information page to see your membership record and status. If you are a voting-eligible member (active Supporting, Contributing, and Fellow members of the PSF) and do not already have a login, please create an account on psfmember.org and then email psf-elections@pyfound.org so we can link your membership to your account. Please ensure you have an account linked to your membership so that we can have the most up-to-date contact information for you in the future.

How to affirm your intention to vote

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

PSF Bylaws

Section 4.2 of the PSF Bylaws requires that “Members of any membership class with voting rights must affirm each year to the corporation in writing that such member intends to be a voting member for such year.”

Our motivation is to ensure that our elections can meet quorum as required by Section 3.9 of our bylaws. As our membership has grown, we have seen that an increasing number of Contributing and Fellow members with indefinite membership do not engage with our annual election, making quorum difficult to reach.

An election that does not reach quorum is invalid. This would cause the whole voting process to be re-held, resulting in fewer voters and an undue amount of effort on the part of PSF Staff.

Recent updates to membership and voting

If you were formerly a Managing member, your membership has been updated to Contributing as of June 25th, 2025, per last year’s Bylaw change that merged Managing and Contributing memberships.

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 voted last year, you will automatically be added to the 2025 voter roll. Please note: If you removed or changed your email on psfmember.org, you may not automatically be added to this year's voter roll.

What happens next?

You’ll get an email from OpaVote with a ballot on or right before September 2nd, and then you can vote!

Check out our PSF Membership page to learn more. If you have questions about membership, nominations, or this year’s Board election, please email psf-elections@pyfound.org or join the PSF Discord for the upcoming Board Office Hours on August 12th, 9 PM UTC. You are also welcome to join the discussion about the PSF Board election on our forum.

Notice of Python Software Foundation Bylaws Change - Effective July 23, 2025

2025-07-08T11:21:00.001-04:00

This post serves as notice that the Board of the Python Software Foundation has resolved to amend the Bylaws, effective July 23, 2025, to remove a condition of the Bylaws that would prevent the Foundation from complying with data privacy laws including those in effect in the European Union, the United Kingdom, and the State of California.

Section 3.8 of the Bylaws grants Voting Members the right to request the list of Voting Members’ names and email addresses. As written, this data must be given unconditionally, which would violate the previously mentioned laws. The amendment we are making grants the Foundation the ability to place conditions upon the use of that list in a way that allows us to comply with data privacy laws.

The full change can be found at https://github.com/psf/bylaws/pull/7/files

The Board determined that this change was time-sensitive and chose to amend the Bylaws without prior consultation with Voting Members. We greatly value the input of our membership in the governance of the Foundation. Therefore, we have opted to make only the most minimal change that will enable the Foundation to comply with data privacy laws and protect our members, while preserving the spirit of the text that the membership agreed to when adopting these Bylaws.

A future Bylaws update will be offered to the membership at a future election. As we are less than 3 months from the 2025 Board election, we are targeting the 2026 Board election to allow the membership to discuss further amendments for the membership to vote upon.

Thanks,

The Python Software Foundation Board

Thinking about running for the PSF Board? Let’s talk!

2025-07-02T08:08:00.001-04:00

PSF Board elections are a chance for the community to choose representatives to help the PSF 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 PSF Board on our website. (Dawn Wages, Jannis Leidel, Kushal Das, and Simon Willison are at the end of their current terms.)

Office Hours Information

This year, the PSF Board is dedicating a few of their regular Office Hour sessions on the PSF Discord to the topic of the election. This is your chance to connect with current board members to ask questions and learn more about what being a part of the Board entails.

The two upcoming Office Hour sessions will be dedicated to the topic of the election:

Tuesday, July 8th, 1 PM UTC - Nominations
Tuesday, August 12th, 9 PM UTC - Membership & general election questions

We welcome you to join the PSF Discord to participate in Office Hours. The server is moderated by PSF Staff and locked between office hours sessions. If you’re new to Discord, check out some Discord Basics to help you get started.

Who runs 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:

Life as Python Software Foundation Director video on YouTube
FAQs About the PSF Board video on YouTube
Our past few Annual Impact Reports:

Nomination info

You can nominate yourself or someone else. We encourage you to reach out to people before you nominate them to ensure they are enthusiastic about the potential of joining the Board. Nominations open on Tuesday, July 29th, 2:00 pm UTC, so you have a few weeks to research the role and craft a nomination statement. The nomination period ends on Tuesday, August 12th, 2:00 pm UTC. There will be a 'call for nominations' blog post with more information and resources about nominations coming soon.

The PSF's 2024 Annual Impact Report is here!

2025-06-17T08:25:00.001-04:00

2024 was another remarkable year of growth for the Python Software Foundation! Python became the most popular language on GitHub, and worldwide community engagement was at an all-time high. We expanded our impact by welcoming our inaugural PyPI Support Specialist, Maria Ashna, the revival of the User Success and Education and Outreach Workgroups, and continued investment in grants, infrastructure, and accessibility. We’ve captured some of the key numbers, details, and information in our latest Annual Impact Report.

Some highlights of what you’ll find in the report include:

A letter from our Executive Director, Deb Nicholson
Notes from our PyCon US 2025 Chair and Co-Chair, Elaine Wong and Jon Bonafato, and PSF Board of Directors Chair, Dawn Wages
Updates on the achievements and activities of our Developers-in-Residence: Łukasz Langa, Petr Vicktorin, Serhiy Storchaka, and Seth Larson
An overview of PyPI in 2024, including:

Impressive and ever-growing stats
An overview of the work and accomplishments of our PyPI Safety & Security Engineer, Mike Fiedler

A celebration and summary of PyCon US 2024
A highlight of our 20 amazing Fiscal Sponsorees
Sponsors who generously supported our work and the Python ecosystem
An overview of PSF Financials, including a consolidated financial statement and grants data

We hope you check out the report, share it with your Python friends, and let us know what you think! Find us on social media (Mastodon, Bluesky, X, LinkedIn), or share your thoughts on the Python Discuss thread.

2025 PSF Board Election Schedule

2025-06-12T14:33:00.005-04:00

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 26th, 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 26th 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

Life as Python Software Foundation Director video
FAQs About the PSF Board video
Our past few Annual Impact Reports:

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

2025-06-12T09:34:00.001-04:00

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:

How can we make breaking changes less painful?: talk by Itamar Oren

An Uncontentious Talk about Contention: talk by Mark Shannon
State of Free-Threaded Python: talk by Matt Page
Fearless Concurrency: talk by Matthew Parkinson, Tobias Wrigstad, and Fridtjof Stoldt
Challenges of the Steering Council: talk by Eric Snow
Updates from the Python Docs Editorial Board: talk by Mariatta
PEP 772 - Packaging Governance Process: talk by Barry Warsaw and Pradyun Gedam
Python on Mobile - Next Steps: talk by Russell Keith-Magee
What do Python core developers want from Rust?: talk by David Hewitt
Upstreaming the Pyodide JS FFI: talk by Hood Chatham
Lightning Talks: talks by Martin DeMello, Mark Shannon, Noah Kim, Gregory Smith, Guido van Rossum, Pablo Galindo Salgado, and Lysandros Nikolaou

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

2025-06-12T09:32:00.008-04:00

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

2025-06-12T09:32:00.005-04:00

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”.

“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

2025-06-12T09:32:00.004-04:00

“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

2025-06-12T09:32:00.003-04:00

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

2025-06-12T09:32:00.001-04:00

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?

2025-06-12T09:31:00.004-04:00

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.