Python Software Foundation News

Announcing Python Software Foundation Fellow Members for Q3 2023! 🎉

2024-01-18T09:44:00.000-05:00

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

Dustin Ingram

LinkedIn, Github, Social, Website

Marlene Mhangami

Twitter, GitHub, Website

Nikita Sobolev

GitHub, Website

Raquel Dou

Thank you for your continued contributions. We have added you to our Fellow roster online.

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 online: https://www.python.org/psf/fellows/. 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 are currently in review. We are accepting nominations for Quarter 1 2024 through February 20, 2024.

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

Announcing the Deputy Developer in Residence and the Supporting Developer in Residence

2024-01-18T08:46:00.000-05:00

We’re very happy to welcome Petr Viktorin as the Deputy Developer in Residence! Better yet, he is joined by Serhiy Storchaka as the Supporting Developer in Residence. This transforms the residency program into a full blown team! We couldn’t be happier.

It’s exciting to be able to begin to realize the full vision of the Developers in Residence program, with special thanks to Bloomberg for making it possible for us to bring Petr on board. The initial idea behind the Developer in Residence was to have three to five people hired directly by the Python Software Foundation to help with developer efficiency at CPython, where most of the contributors are volunteers. Three to five people is a good amount to allow for handling both day-to-day tasks, as well as planning and executing on larger-scale projects.

We were only able to start with a single Developer in Residence, initially sponsored by Google for the initial year, and by Meta for the following two years. We were clear that adding more developers in residence would multiply the impact of the role but, of course, the big question is funding. Fortunately, the success of the initial one-person program allowed for a new sponsor to participate, interested in extending the program with another developer. Thank you, Bloomberg!

We announced the job opening back in July, and the interview process was extensive. The Foundation received close to 100 applications, and it was a very tough decision, as most were excellent candidates. One surprise in particular was that despite the Deputy role being described as targeting programmers of various experience levels, we received many more applications from Python core developers than during the initial Developer in Residence job opening.

Naturally, the core developers bubbled up in the interview process. We were especially impressed by Petr Viktorin’s experience with maintaining Python at Red Hat, his interest in the C API, and his long-term existing contributions to Python. Given the transformative recent developments inside the interpreter in terms of performance and scalability, Petr’s skillset was the perfect match. We’re excited he accepted the offer!

However, there was one more person who we were also ready to hire on the spot: Serhiy Storchaka, a rare example of a core developer generalist, with plenty of C experience and contributions across the entire codebase. Consistently one of the top most prolific contributors to Python, we felt like we needed to secure him as a member for the Residents team. Unexpectedly, a generous anonymous donation allowed us to hire Serhiy as well. Thank you!

We are calling the role the Supporting Developer in Residence to make it clear the funding level here isn’t as high as in the Deputy case. Please contact us if your organization can help sponsor Serhiy to bump him to the Deputy salary. Serhiy sure deserves it!

After an initial meeting with the Steering Council, the Residents team is now ready to take on a more active role in shaping the development of the language. The Council advised that while every team member is expected to prioritize unblocking other contributors and keeping the developer experience smooth, with three people on the team each Resident can now also spend a percentage of their time on feature work aligned with their interests.

There are some exciting times ahead for Python!

EU’s Cyber Resilience Act Passes with Wins for Open Source

2024-01-12T10:40:00.000-05:00

Back in April, we wrote to the community about our concerns for the future of the open source ecosystem generally and CPython and PyPI specifically if the European Cyber Resilience Act (CRA) were to pass in the form that had been shared. At the time, we were worried that in the course of providing software for anyone to use, analyze or change that the PSF and/or the Python community might become legally responsible for security issues in the products that are built with the code components that we are providing for free. We asked for increased clarity, specifically:

“Language that specifically exempts public software repositories that are offered as a public good for the purpose of facilitating collaboration would make things much clearer. We'd also like to see our community, especially the hobbyists, individuals and other under-resourced entities who host packages on free public repositories like PyPI be exempt.”

The good news is that CRA text* changed a lot between the time the open source community – including the PSF – started expressing our concerns and the Act’s final text which was cemented on December 1st. That text introduces the idea of an “open source steward.”

“'open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;” (p. 76)

Furthermore, the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

“More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity.” (p. 10)

So are we totally done paying attention to European legislation? Ah, while it would be nice for the Python community to be able to cross a few things off our to-do list, that’s not quite how it works. Firstly, the concept of an “open source steward” is a brand new idea in European law. So, we will be monitoring the conversation as this new concept is implemented or interacts with other bits of European law to make sure that the understanding continues to reflect the intent and the realities of open source development. Secondly, there are some other pieces of legislation in the works that may also impact the Python ecosystem so we will be watching the Product Liability Directive and keeping up with the discussion around standard-essential patents to make sure that the effects on Python and open source development are intentional (and hopefully benevolent, or at least benign.)

Thank you to Open Forum Europe (OFE) — especially Ciarán O’Riordan – for bringing the FOSS community together to share our thoughts on how the proposed text would affect open source, thinking about how the goals of the proposed act might be achieved without unintentionally creating a chilling effect for open source and communicating those ideas to legislators. OFE’s work to coordinate our efforts certainly made it easier for the PSF’s concerns to be heard and I’m fairly certain it made it easier for legislators to assess and consider impacts to the open source ecosystem when we were able to speak with one voice.

*The entire Regulation is published here, if you want to dive into the text more deeply.

Announcing the Hidden Figures of Python Podcast!

2023-12-12T03:00:00.034-05:00

The Python Software Foundation is excited to share the launch of the Hidden Figures of Python, a new podcast series created by the PyPodcats. The Hidden Figures of Python series aims to uplift underrepresented folks and their inspiring stories. Episode 0 is available now on the PyPodcats website, Spotify, Apple Podcasts, and the PSF YouTube channel.

Hidden Figures of Python podcast series is hosted by the PyPodcats team: Cheuk Ting Ho, Georgi Ker, Mariatta Wijaya, and Tereza Iofciu. Our aim is to highlight voices of underrepresented group members of the Python community.

Within the realm of popular Python community podcasts, women make up less than 15% of podcast speaker guests.

We know that there are in fact many underrepresented members in our community who are contributing to the Python community, and they deserve to be seen and heard by the rest of us.

By creating this podcast series, we hope for the rest of the Python community to learn more about the underrepresented community members and to appreciate their contributions to the global Python community.

The Hidden Figures of Python Podcast has been created with care by treasured members of the Python and PSF community. We congratulate and applaud Cheuk, Georgi, Mariatta, and Tereza for launching the series and for everything they contribute to Python and the PSF!

Support for community projects like the PyPodcats comes from our sponsors, but also from folks like you through donations and Memberships. Make sure to check out our blog post on our end of year Membership and donations drive. Your gifts and support means the world to us. We’re incredibly grateful to be in community with you!

It's time for our annual year-end PSF fundraiser and membership drive 🎉

2023-11-15T10:30:00.011-05:00

Support Python in 2023!

There are two ways to join in the drive this year:

Donate directly to the PSF! Every dollar makes a difference. (Does every dollar also make a puppy’s tail wag? We make no promises, but may you should try, just in case? 🐶)

Become a member! Sign up as a Supporting member of the PSF. Be a part of the PSF, and help us sustain what we do with your annual support.

Or, heck, why not do both? 🥳

Your Donations:

Keep Python thriving

Invest directly in CPython and PyPI progress

Bring the global Python community together

Make our community more diverse and robust every year

Let’s take a look back on 2023:

PyCon US - We held our 20th PyCon US, in Salt Lake City and online, which was an exhilarating success! For the online component, PyCon US OX, we added two moderated online hallway tracks (in Spanish and English) and saw a 33% increase in virtual engagement. It was great to see everyone again in 2023, and we’re grateful to all the speakers, volunteers, attendees, and sponsors who made it such a special event.

Security Developer in Residence - Seth Larson joined the PSF earlier this year as our first ever Security Developer-in-Residence. Seth is already well-known to the Python community – he was named a PSF Fellow in 2022 and has already written a lot about Python and security on his blog. This critical role would not be possible without funding from the OpenSSF Alpha-Omega Project.

PyPI Safety & Security Engineer - Mike Fiedler joined the PSF earlier this year as our first ever PyPI Safety & Security Engineer. Mike is already a dedicated member of the Python packaging community – he has been a Python user for some 15 years, maintains and contributes to open source, and became a PyPI Maintainer in 2022. You can see some of what he's achieved for PyPI already on the PyPI blog. This critical role would not be possible without funding from AWS.

Welcome, Marisa and Marie! - In 2023 we were able to add two new full time staff members to the PSF. Marisa Comacho joined as Community Events Manager and Marie Nordin joined as Community Communications Manager. We are excited to add two full time dedicated staff members to the PSF to support PyCon US, our communications, and the community as a whole.

CPython Developer in Residence - Our CPython Developer in Residence, Łukasz Langa, continued to provide trusted support and advancement of the Python language, including oversight for the releases of Python 3.8 and 3.9, adoption of Sigstore, and stewardship of PEP 703 (to name a few of many!). Łukasz also engaged with the community by orchestrating the Python Language Summit and participating in events such as PyCon US 2023, EuroPython, and PyCon Colombia. This critical role would not be possible without funding from Meta.

Authorized as CVE Numbering Authority (CNA) - Being authorized as a CNA is one milestone in the Python Software Foundation's strategy to improve the vulnerability response processes of critical projects in the Python ecosystem. The Python Software Foundation CNA scope covers Python and pip, two projects which are fundamental to the rest of Python ecosystem.

Five new Fiscal Sponsorees - Welcome to Bandit, BaPya, Twisted, PyOhio, and North Bay Python as new Fiscal Sponsorees of the PSF! The PSF provides 501(c)(3) tax-exempt status to fiscal sponsorees and provides back office support so they can focus on their missions.

Our Thanks:

Thank you for being a part of this drive and of the Python community! Keep an eye on this space and on our social media in the coming weeks for updates on the drive and the PSF 👀

Your support means the world to us. We’re incredibly grateful to be in community with you!

The Python Sofware Foundation receives the Wonderfully Welcoming Award from GitHub!

2023-11-09T18:00:00.022-05:00

[November 9th, 2023] - The Python Software Foundation is delighted to announce that we are a recipient of a GitHub Award under the Wonderfully Welcoming category, awarded on November 9th at GitHub Universe 2023 in San Francisco, CA, USA. This award exemplifies all the Python community strives to be—enthusiastic, dedicated to encouraging use of the language, and committed to building a diverse and friendly community. We are proud of the Python community for embodying our values on GitHub and this award truly belongs to every contributor. We’re incredibly grateful to be in community with you.

GitHub shares:

The GitHub Awards celebrates the outstanding contributions and achievements in the developer community by honoring individuals, projects, and organizations for creating an outsized positive impact on the community.

Python Software Foundation (@psf) is not just a hub for Python development; it's a community that embraces diversity and inclusion at its core. Through initiatives like PyCon Charlas, PSF breaks language barriers, providing a platform for Spanish-speaking contributors. It also champions gender diversity by backing the pioneering PyLadiesCon.

Above all, the PSF is committed to a respectful and safe community experience, fortified by a strong Code of Conduct. It also extends accessibility through captioning and is vigilant about health and safety measures. At PSF, it's not just about code; it's about the people behind it.

The Wonderfully Welcoming Award recognizes people or projects that have been the most welcoming and seen an increasing amount of contributors.

The PSF Executive Director, Deb Nicholson, states: “We believe that empowering new participants is key to the growth and success of the open source movement. We want to thank GitHub for shining a spotlight on the human side of open source community work.”

The Python Software Foundation is a non-profit membership organization devoted to advancing open source technology related to the Python programming language. Our mission is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

If you would like to help advance our mission, please consider supporting us with a donation!

Join the Python Developers Survey 2023: Share and learn about the community!

2023-11-08T14:51:00.002-05:00

This year we are conducting the seventh iteration of the official Python Developers Survey. The goal is to capture the current state of the language and the ecosystem around it. By comparing the results with last year’s, we can identify and share with everyone the hottest trends in the Python community and the key insights into it.

We encourage you to contribute to our community’s knowledge by sharing your experience and perspective. Your participation is valued! The survey should only take you about 10-15 minutes to complete.

Contribute to the Python Developers Survey 2023!

The survey is organized in partnership between the Python Software Foundation and JetBrains. After the survey is over, we will publish the aggregated results and randomly choose 20 winners (among those who complete the survey in its entirety), who will each receive a $100 Amazon Gift Card or a local equivalent.

Announcing our new Community Communications Manager!

2023-10-27T12:13:00.000-04:00

We announced our search for our first Community Communications Manager back in June, and after a thorough search, we are beyond excited to announce that Marie Nordin is the newest addition to our team! Reporting to Loren Crary, Director of Resource Development, Marie joins the PSF as a longtime contributor in Open Source, an experienced community organizer, and an enthusiastic communicator.

Marie will be responsible for establishing a PSF communications calendar, including annual messaging, newsletters, and blog posts. She will also partner with our Executive Director, Deb Nicholson, and other staffers to enhance our support for the Python community with a variety of initiatives. As the first Community Communications Manager at the PSF, Marie’s work will be made up of both routine and experimental projects, as well as helping to fill some of the gaps in our tiny but mighty team.

Marie shares, “I’m thrilled to join the PSF team to help amplify the stories and voices of the Python community. I look forward to learning, supporting, and connecting with you all!”

Marie has a background in community architecture, project/program management, Code of Conduct, and graphic design. A Visual Media graduate from the Rochester Institute of Technology, she first learned of Free and Open Source Software and culture at Open@RIT. Marie went on to become an Outreachy intern in 2013 for the Fedora Project working on Fedora Badges design. After six years of contributing to Fedora in various parts of the project, Marie joined Red Hat’s Open Source Program Office as the Fedora Community Action and Impact Coordinator and later on as a Code of Conduct Specialist.

We hope everyone in the Python community will join us in welcoming Marie with ideas and collaboration as she settles in. We are very happy to be able to add a staff member dedicated full-time to such important aspects of our work, and we feel very fortunate to have found someone with Marie's wealth of experience and skills to take on this new role. We're excited to see what Marie can achieve together with the PSF and the Python community!

September & October Board Votes

2023-10-20T11:16:00.000-04:00

We’re writing today because we know the process of the PSF Board’s review of DjangoCon Africa’s recent grant application caused concern, disappointment, and confusion for some of our community. We want to take time to explain that process clearly, and how we plan to improve moving forward.

First of all, we’re pleased to say that on October 11th the PSF Board voted to approve DjangoCon Africa’s $9,000 grant request. We’re wishing lots of luck to the organizers and everyone involved–check it out here! DjangoCon Africa is a community-run event that will take place for the first time this year November 6-11 in Zanzibar, Tanzania.

If you are reading this, you probably already know that the PSF runs a grants program that disperses funds to Python events and groups, (info on how to apply for your own event here). Last year we gave out $215,000 to 138 groups in 42 countries. For the majority of grants, the decision of whether or not to fund a grant request is made by consensus by the Grants Working Group, which is made up of volunteers from the community (huge thanks always due to them for what they do.) Some grants require the Board to review and vote on them instead: grant requests over $10,000; grants with a per person per day cost greater than $15; and grants that the Grants Working Group can’t reach a consensus decision on.

Because after discussion the working group couldn’t reach a consensus on the DjangoCon Africa request, it came to the Board for a vote instead. The Board first discussed the request in our September meeting, however the resolution to grant the request didn’t pass because the majority of directors abstained (6 abstentions, 4 yes votes, 0 no votes). The board members who abstained had a variety of reasons, including our Board Chair who was required to abstain because she is an organizer of DjangoCon Africa; others had open questions about the details of the grant request (e.g. related to budget) that we didn’t have time to resolve or had concerns about how to best support our community members with respect to safety, security and equity in the context of international events taking place in jurisdictions with laws that are harmful to certain community members (in this case, the criminalization of homosexuality in Tanzania) but not wanting to apply a new rule unfairly to this event. The reason for each board member's vote is always as nuanced as the board member casting it each time a vote comes to decision. In this case, it was agreed that there was not sufficient time in the board meeting to review the merits of the application, which bears no fault of the DjangoCon Africa organizing team.

The request came back in front of the Board for our October meeting, at which point we’d been able to get more information, time to review, and read letters on the event's impact. This vote passed (1 abstention, 10 yes votes, 0 no votes), which we believe reflects the values of an informed Board working together. We’re thrilled to be able to support the Django and Python communities in Africa in general and in Tanzania in particular, and especially for what is shaping up to be a great new annual event. Every decision made, with or without feedback from the community, affects dozens to hundreds to thousands of Pythonistas and the Board is always cognizant that our desire to provide timely, enthusiastic support must be balanced with the responsibility to steward funds carefully and fairly.

Because of the harm expressed in the community due to the Board’s process, we will be conducting a retrospective on this process specifically and the Board's approach to grants in general. To be completely clear, the points that will be discussed in our retrospective have everything to do with process improvements and event inclusivity and nothing to do with the merits of the event in question. We’re likely to address process issues in the short term and strategy over a longer period of time. The discussed topics are likely to include, but are not limited to:

The PSF's approach to grant making in general
How to best serve the global community, especially marginalized members for whom safety can be a concern when traveling
Parliamentary procedures

We value community perspective. If you would like to share any thoughts or feelings on this topic, please feel free to share your thoughts – anonymously if you prefer – via this form.

Once complete, our retrospective can be found in our meeting minutes archive along with the minutes for all of the board's previous meetings.

Thank you for helping us make the Python community the best it can be,
The PSF Board of Directors

Security Developer-in-Residence 2023 Q3 Report

2023-10-17T14:00:00.005-04:00

It’s been three months since I was first hired as the inaugural Security Developer-in-Residence. I’m quite proud of what I’ve accomplished so far and think it shows the value of investing into the security of Open Source through hiring folks to work full-time in roles like “Developer-in-Residence” programs. I’m thankful to the Alpha-Omega project at OpenSSF for funding this work. Let’s review all of the accomplishments in the first quarter of this role and what to look forward to in the next quarter.

If you’d like to follow along with my work more closely you can subscribe to my personal blog where I publish weekly updates about the work I’m doing. If you have questions or thoughts about what I’m working on you can contact me via email: seth@python.org.

The Python Software Foundation authorized as a CVE Numbering Authority (CNA)

Back in late August the Python Software Foundation received notice that we’d successfully completed onboarding and had been authorized by CVE as a CVE Numbering Authority or “CNA”. The Python Software Foundation CNA scope covers Python and pip, two projects which are fundamental to the rest of the Python ecosystem.

Being a CNA means that the PSF can offer staffing to improve the sustainability and responsiveness of coordination and vulnerability disclosure work for covered projects. The PSF CNA also provides rich metadata for CVE records and advisories, including remediation information, so upgrading or patching for vulnerabilities is as straightforward as possible for downstream users of Python.

CPython vulnerability advisories available in Open Source Vulnerability database

The Python Software Foundation now hosts a vulnerability database on GitHub using the Open Source Vulnerability format (OSV). This database contains vulnerability information for CPython in addition to vulnerabilities getting published to the security-announce@python.org mailing list. The historical vulnerability information was sourced from Victor Stinner’s “python-security” project in order to provide a complete history of vulnerabilities in CPython.

By using the OSV format the vulnerabilities can be ingested and processed by the Open Source Vulnerability database which can be searched or queried using an API for machine-consumable vulnerability information.

Having vulnerability information in a machine-consumable format enables tools that scan software deployments for vulnerabilities to easily provide accurate and automatically updated reports for CPython. The Open Source Vulnerability database also is more discoverable compared to the CVE database, having a readily available public API to query for vulnerabilities, products, and versions.

Python Security Response Team

I have been helping coordinate reports to the Python Security Response Team (PSRT) since joining the role. This work includes reviewing all reports, gathering information from reporters, discussing timelines, and working with core developers to create and release fixes and advisories in a coordinated manner. I also worked with CVE to get CVE IDs assigned on behalf of reports before the PSF was designated as a CNA.

I revitalized the security-announce@python.org mailing list to use for future advisory announcements so interested parties can be notified as soon as new vulnerabilities are published (subscribe to the linked list if you’d like to receive these). I coordinated the two recent vulnerabilities affecting CPython (CVE-2023-40217 and CVE-2023-41105) end-to-end from report to published advisory.

Doing this coordination work frees up volunteers on the PSRT to focus on determining whether a report is a vulnerability and working on fixes. I’m also working to further reduce the manual coordination work required by PSRT by moving the reporting and triage process to GitHub using GitHub Security Advisories.

OpenSSF Day Europe 2023

I co-presented a talk titled “We Make Python Safer than Ever” at OpenSSF Day Europe 2023 with PSF Board Member and OpenSSF Community Manager Cheuk Ting-Ho. The slides are available for download and the talk recording is available to watch on YouTube.

The talk introduced the Security Developer-in-Residence role, went over the challenges that are unique to securing Open Source and Python ecosystems, described completed and future projects to make the Python ecosystem more secure, and gave a list of items that viewers themselves could do right away to make their own usage of Python more secure.

Sigstore signatures for Python release artifacts

Python releases include signatures from the Release Managers using the signing tool “Sigstore”. These signatures mean you can be sure that a given release artifact wasn’t tampered with and was created and vetted by the Release Manager for a given Python release.

I did an audit of existing signatures and found some discrepancies between the documented identities and providers and what was published for each release. I worked with Release Managers to fix the discrepancies and added extra safeguards to release tooling to ensure signatures are verifiable as documented. I also was able to back-fill the new Sigstore signature format from existing verification materials to make verifying signatures even easier!

$ python -m sigstore verify identity \
    --bundle Python-3.12.0.tgz.sigstore \
    --cert-identity thomas@python.org \
    --cert-oidc-issuer https://accounts.google.com \
    Python-3.12.0.tgz

Having consistent artifact signatures is important because any discrepancies while consuming these signatures should raise red flags for downstream users and redistributors. This also helps build confidence in the new signing method over existing methods like GPG.

Adoption of system trust stores via Truststore

There are three packaging tools (pip, PDM, and Conda) that are important to the Python ecosystem that are at various stages of adopting “Truststore”, a library that I authored prior to joining the PSF to enable Python projects to use system trust stores for verifying HTTPS certificates instead of relying on certifi for certificates.

PDM has started using Truststore by default starting in v2.9.0, Conda plans to release optional support for Truststore in v23.9.0, and pip already has optional support for Truststore since v22.2 but has recently bundled Truststore into pip to remove the need to “bootstrap” into Truststore by pre-installing the library.

Using the system trust store is important because any removals to a trust store (like for e-Tugra root certificates) must be propagated to all end systems in order to avoid “monster-in-the-middle” attacks. Further challenging this propagation is that some tools like pip bundle certifi as a means of bootstrapping, which means that you need to upgrade both certifi and pip in order to completely propagate updates to certifi’s certificate bundle.

This propagation is better suited to a centralized system like an OS package manager or an automatic centralized authority or IT department keeping the trust bundles up-to-date, which can only happen through using system trust stores.

Recently the Python implementation PyPy added support for Python 3.10, thus enabling PyPy to also use Truststore. I subsequently added support and backwards compatibility tests for PyPy to Truststore to ensure all compliant implementations of Python can take advantage of the benefits.

Future Projects and Challenges

Software Bills-of-Materials for CPython

Software Bill-of-Materials (SBOMs) are a hot topic in the world of software security due to new government requirements and improved software and vulnerability management tooling. Many tools generate or consume SBOMs as a universal format for describing software and its components and then matching those components to known vulnerabilities.

I've started working on an authoritative SBOM for the CPython project, you can follow along in this GitHub repository if you are interested. This project is early and this will not be the final product or place where this information is published, this is only a place to experiment and get feedback on the approach and outputs before putting the final infrastructure in place.

I started with the most straightforward release artifact, the source tarball, and I am planning to tackle the binary installers later since they'll require more research into the release processes. There is a work-in-progress SBOM file for Python-3.12.0.tgz available in the sboms/ directory on the repository.

Using vulnerability scanning tools I was able to see not only vulnerabilities in CPython, but crucially in the bundled subcomponents like expat and pip. Without an SBOM the subcomponents to a project like CPython likely wouldn’t get detected properly and thus would be not covered by vulnerability management tooling.

The challenges here will be integrating the creation and maintenance of the SBOMs into the CPython development and release processes while minimally disrupting other core developers workflows and avoiding the need to develop and maintain custom tooling for CPython’s specific use-case.

Tracking bundled dependencies in Python packages

Python is the premier “glue” language, meaning that Python is often used alongside many other programming languages like C, C++, Rust, Go, and more thanks to Python C API. This benefit also means that Python packages can include projects and source code from sources both within and external to the Python ecosystem.

Those projects and source code from outside the Python ecosystem present a problem for vulnerability scanners which typically rely on explicit metadata about projects and dependencies in order to find vulnerabilities in software manifests. Without a clear way to encode this information into packaging metadata it’s impossible to signal these dependencies even if a maintainer of a project wants to do so.

C and C++ projects in particular pose additional issues due to their existence outside of a programming language packaging ecosystem like Python with PyPI or JavaScript and NPM. This makes tracking usage and vulnerabilities in these projects difficult and relies on other identification schemes like CPEs or redistributions in other packaging ecosystems like RPM/DEB. Without this information scanners today miss vulnerable components bundled in Python packages, meaning developers won’t know how or when their Python deployments are vulnerable.

Solving this issue completely will be a multi-step process, starting with being able to encode information about bundled projects into Python distributions which will require a new packaging PEP. After the standard has been decided, next is getting bundled project metadata automatically captured to avoid needing an entire ecosystem to manually annotate every project. Concurrently to this I’ll collaborate with SBOM generation tooling to add support for consuming the new standard and adding that information to SBOMs generated from Python environments.

CPython and pip release process improvements

CPython and pip are two of the most important projects in the Python ecosystem and each have non-trivial release processes. In an effort to increase the integrity of these projects’ releases I’ve researched and documented their release process and with SLSA’s list of historical supply chain attacks against software projects have been making suggestions and implementing improvements.

These improvements include reproducibility of built artifacts, extra guarantees on the integrity of inputs, automating the build processes to reduce attack surface area to only services like GitHub Actions and Azure Pipelines instead of individuals’ computers, and making it so that in the event of an attack that it would need to be publicly detectable and traceable.

By improving the integrity of these processes I am hoping to prevent disaster scenarios such as malware being injected into Python or pip at the “last mile” before being published to python.org. Injection of malware during build time has happened to multiple other Open Source projects with disastrous results for users. This work means users can be even more confident in their usage of Python and upgrade early and often to take advantage of Python’s latest features.

Python Developers Survey Numbers for 2022!

2023-09-27T11:44:00.000-04:00

We are excited to announce the results of the sixth official annual Python Developers Survey. This work is done each year as a collaborative effort between the Python Software Foundation and JetBrains. Late last year, more than 23,000 Python developers and enthusiasts from almost 200 countries/regions participated in the survey to reveal the current state of the language and the ecosystem around it. (Spoiler alert: Many people are using Python, and 51% are using it for both work AND personal projects.)

https://lp.jetbrains.com/python-developers-survey-2022/

We know the whole Python community finds this work useful. From Luciana Abud, product manager for Visual Studio Code, “Our teams at Microsoft are truly grateful to the Python Software Foundation and JetBrains for orchestrating the Python Developers Survey! The insights we gain allows us to take a data-driven approach to help with prioritizing feature development, addressing pain points, enhancing usability and anticipating future needs. This survey is invaluable in shaping our approach and continuously improving the Python development experience within the VS Code ecosystem!”

We’d love to hear how you use these numbers, so please share your thoughts on social media, mentioning @jetbrains and @ThePSF with the #pythondevsurvey hashtag. We are also open to any suggestions and feedback related to this survey which could help us run an even better one next time.

Announcing Python Software Foundation Fellow Members for Q2 2023! 🎉

2023-09-14T14:52:00.000-04:00

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

Esteban Maya Cadavid

Twitter, LinkedIn, Github, Instagram

Martijn Pieters

Stack Overflow, GitHub, Website

Philip Jones

Mastodon, GitHub, Website

Yifei Wang

GitHub

Thank you for your continued contributions. We have added you to our Fellow roster online.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: https://www.python.org/psf/fellows/. 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 are currently in review. We are accepting nominations for Quarter 4 through November 20, 2023.

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

The Python Software Foundation has been authorized by the CVE Program as a CVE Numbering Authority (CNA)

2023-08-29T15:26:00.000-04:00

When a vulnerability is disclosed in software you're depending on, the last thing you want is for the remediation process to be confusing or ad-hoc. Towards the goal of a more secure and safe Python ecosystem, the Python Software Foundation has been authorized by the CVE Program as a CVE Numbering Authority (CNA).

Being authorized as a CNA is one milestone in the Python Software Foundation's strategy to improve the vulnerability response processes of critical projects in the Python ecosystem. The Python Software Foundation CNA scope covers Python and pip, two projects which are fundamental to the rest of Python ecosystem.

By becoming a CNA, the PSF will be providing the following benefits to in-scope projects:

Paid staffing for CNA operations rather than requiring volunteer time.
Quicker allocations of CVE IDs after a vulnerability is reported.
Involvement of each projects' security response teams during the reporting of vulnerabilities.
Richer published advisories and CVE Records including descriptions, metadata, and remediation information.
Consistent disclosures and publishing locations.

CNA operations will be staffed primarily by the recently hired Security Developer-in-Residence Seth Michael Larson, Ee Durbin, and Chloe Gerhardson.

The PSF wants to help other Open Source organizations and will be sharing lessons learned and developing guidance on becoming a CNA and day-to-day operations.

To be alerted of newly published vulnerabilities in Python or pip, subscribe to the security-announce@python.org mailing list for security advisories. There is also a new advisory database published to GitHub using the machine-readable Open Source Vulnerability (OSV) format.

If you'd like to report a security vulnerability to Python or pip, the vulnerability disclosure policy is available on python.org.

The mission of the Common Vulnerabilities and Exposures (CVE®) Program is to
identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There
is one CVE Record for each vulnerability in the catalog. The vulnerabilities are
discovered then assigned and published by organizations from around the world
that have partnered with the CVE Program. Partners publish CVE Records to
communicate consistent descriptions of vulnerabilities. Information technology
and cybersecurity professionals use CVE Records to ensure they are discussing
the same issue, and to coordinate their efforts to prioritize and address the
vulnerabilities.

The Python Software Foundation (PSF) is the non-profit organization behind Python and PyPI. Our mission is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers. The PSF supports the Python community using corporate sponsorships, grants, and donations. Are you interested in sponsoring or donating to the PSF so it can continue supporting Python and its community? Check out our sponsorship program, donate directly here, or contact our team!

Announcing Our New PyPI Safety & Security Engineer!

2023-08-04T12:32:00.000-04:00

We announced our intention back in May to fill this role with generous funding by Amazon Web Services (AWS), and after a thorough search, we are delighted to announce Mike Fiedler is joining the team! He joins the PSF for the next year as our first ever PyPI Safety & Security Engineer. Mike is already a dedicated member of the Python packaging community – he has been a Python user for some 15 years, maintains and contributes to open source, and became a PyPI Maintainer in 2022.

This critical role would not be possible without funding from AWS: "We are happy to be able to invest in the sustainable and secure development of Python and PyPI, and we look forward to Mike's contributions." - Tom Callaway, AWS.

Mike begins his work with the Python Packaging Index (PyPI) this week. He says, “Very excited to join the team in improving the safety and security of PyPI for end users, package publishers, maintainers, and PyPI moderators and administrators - that’s a huge audience!” We hope that everyone in the community will join us in welcoming Mike and supporting his critical work for Python packaging!

We are thrilled that for the first time we are able to bring on an engineer who will be dedicated full-time to PyPI. PyPI is a massive project that has become key digital infrastructure serving millions of users. Up until now, PyPI has been almost entirely volunteer-run, depending on a tiny team with only one fraction of one person’s paid time. We’re expecting all PyPI users to have a tangibly improved experience from Mike’s work over the next year. Some of the outcomes we are targeting include increased support for package maintainers including multi-maintainer projects, improvements to reporting infrastructure for malicious projects, as well as a reduced response time for malware reports and account recovery requests. Mike will work closely with our also-recently-announced Security Developer in Residence, Seth Larson.

This role is funded by a substantial investment from AWS, inaugural Security Sponsor for PyPI. AWS has been one of the top sponsors of the Python Software Foundation for the last five years, and our long-term partnership with AWS has also included important in-kind donations of cloud computing infrastructure and services to support PyPI.

Announcing Python Software Foundation Fellow Members for Q1 2023! 🎉

2023-08-02T10:51:00.000-04:00

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

Abhishek Mishra

Twitter, LinkedIn, Website

Barney Gale

GitHub, LinkedIn

Eric Traut

GitHub, LinkedIn

Gina Häußge

Mastodon, GitHub, Website

Grishma Jena

Twitter, LinkedIn, Website, Instagram

Samuel Colvin

Twitter, GitHub

Saptak Sengupta

Mastodon, GitHub, Website

Soon Seng Goh

Thank you for your continued contributions. We have added you to our Fellow roster online.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: https://www.python.org/psf/fellows/. 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 2 nominations are currently in review. We are accepting nominations for quarter 3 through August 20, 2023.

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

Announcing the 2023 PSF Board Election Results!

2023-06-30T20:13:00.000-04:00

It was a really lively and engaged election process for the PSF Board this year! First of all, we want to thank 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 make the PSF better and how to represent the parts of the community that you participate in. We hope that you will continue to think about these issues and share your ideas.

Congratulations to our five new Board members-elect!

Cheuk Ting Ho
Denny Perez
Georgi Ker
Christopher Neugebauer
KwonHan Bae *

We’ll be in touch with all the elected candidates next week to schedule onboarding. * The fifth person is being invited to serve for a year to fill the off-cycle vacancy left by Joannah Nanjekye, who stepped down from the Board.

I’d like to take this opportunity to thank our outgoing board members for their outstanding service; Dustin Ingram, Joannah Nanjekye, Jeff Triplett, Thomas Wouters and Nina Zakharenko. They served on the PSF Board through a particularly eventful time; helping us to navigate the global pandemic, rework PyCon US into a virtual event and hire a new Executive Director. Thank you for supporting the PSF and the Python community through so much change!

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 621 total votes, which easily reached quorum–1/3 of affirmed voting members (877). We’re especially grateful for your patience with navigating the changes to the voting process, which ultimately allowed for a valid election and a more sustainable elections system.

I also want to thank everyone who helped promote this year’s board election, especially Python Community News who took the initiative to cover this year’s election and produced informational videos from each candidate. I also want to highlight the PSF staff members who made some changes to our membership management on the back-end this year, enabling us to affirm voting intention for the first time ever and setting up OpaVote. Thanks to Ee Durbin and Joe Carey!

Finally, it might feel a little early to mention this, but we will have four seats open again next year. If you're interested in running or learning more, we encourage you to reach out to a current board member or two this year and ask them about serving.

Announcing Our New Security Developer in Residence!

2023-06-22T09:50:00.000-04:00

We announced our intention to fill this role back in January, and after a thorough search, we have chosen Seth Michael Larson! He joins the PSF for the next year as our first ever Security Developer-in-Residence. Seth is already well-known to the Python community – he was named a PSF Fellow last year and has already written a lot about Python and security on his blog.

This critical role would not be possible without funding from the OpenSSF Alpha-Omega Project. “At Alpha-Omega, we are excited to support the Python Software Foundation as they improve the security of PyPI, and more generally the Python ecosystem as a whole.” Alpha Omega Representative - Bob Callaway, Google

Seth begins his work with Python and the Python Package Index (PyPI) this week. He says, “The Python community is such a positive part of my life so I'm grateful for this incredible opportunity to contribute back. I'm looking forward to partnering with all of you to build a more secure Python ecosystem for everyone!” We hope that everyone in the community will welcome Seth and help him succeed in his audit and subsequent plans for key security improvements.

This role is funded by a substantial investment from the Open Software Security Foundation (OpenSSF) Alpha-Omega Project. The OpenSSF is a non-profit cross-industry collaboration that brings together leaders to improve the security of open source software by building a broader community, targeted initiatives, and best practices. The OpenSSF unifies many open source security initiatives under one foundation to accelerate work through cross-industry support.

The Python Software Foundation (PSF) is a non-profit whose mission is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers. The PSF supports the Python community using corporate sponsorships, grants, and donations. Are you interested in sponsoring or donating to the PSF so it can continue supporting Python and its community? Check out our sponsorship program, donate directly here, or contact our team!

The 2023 PSF Board Election is Open!

2023-06-20T13:47:00.003-04:00

It’s time to cast your vote! Voting takes place from today Tuesday, June 20, through Friday, June 30, 2023 11:59pm UTC. If you are a voting member of the PSF, you should have gotten an email from “OpaVote Voting Link <noreply@opavote.com>” with your ballot, the subject line will read “Python Software Foundation Board of Directors Election 2023”. If you haven’t seen your ballot by Wednesday, please 1) check your spam folder for a message from “noreply@opavote.com” and if you don’t see anything 2) get in touch by emailing psf-elections@python.org so we can make sure we have the most up to date email for you.

Four seats are open, but you can approve as many candidates as you like. BUT! Choose carefully before you press the big green vote button. Once your vote is cast, it cannot be changed.

We’re overwhelmed by how many of you are willing to contribute to the Python community by serving on the PSF board! Make sure you schedule some time to look at all their statements and choose your candidates carefully. OpaVote doesn’t let you go back and change your vote once you’ve made your choices.

Who can vote? You need to be a Contributing, Managing, Supporting, or Fellow member as of June 15, 2023 and have affirmed your voting intention by June 19, 2023 to vote in this election. Read more about our membership types here or if you have questions about your membership status please email psf-elections@python.org

Board Candidates for 2023 are Announced!

2023-06-16T13:19:00.002-04:00

What an exciting list! Please take a look at who is running for the PSF Board this year here. This year there are 4 seats open on the PSF board. You can see who is on the board currently here. (Dustin Ingram, Jeff Triplett, Nina Zakharenko and Thomas Wouters are at the end of their current terms.)

Board Election Timeline:

Nominations are open, Thursday, June 1st, 2:00 pm UTC
Board Director Nomination cut-off: Thursday, June 15, 11:59 pm UTC
Voter application cut-off date: Thursday, June 15, 11:59 pm UTC
Announce candidates: Friday, June 16th
Voting start date: Tuesday, June 20, 12:01 am UTC
Voting end date: Friday, June 30, 11:59 pm UTC

Not sure what UTC is for you locally? Check here!

Voting takes place from today Tuesday, June 20, through Friday, June 30, 2023 11:59pm UTC. Check here to see how much time you have left to vote. If you are a voting member of the PSF, you will get an email from “OpaVote Voting Link <noreply@opavote.com>” with your ballot, the subject line will read “Python Software Foundation Board of Directors Election 2023”. If you haven’t seen your ballot by Wednesday, please 1) check your spam folder for a message from “noreply@opavote.com” and if you don’t see anything 2) get in touch by emailing psf-elections@python.org so we can 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@python.org You are welcome to join the discussion about the PSF Board election on Slack or on our forum.

Affirming your PSF Membership voting status

2023-06-07T13:57:00.000-04:00

Every PSF Voting Member (Supporting, Managing, Contributing, and Fellow) needs to affirm their membership in order to vote in this year’s election.

This year’s Board Election begins June 20th, and voter eligibility cut-off is June 15th. You should have received an email with instructions and you need to affirm your voting rights before June 15th in order to participate in this year's Board Election. Email will be from "psf@psfmember.org <Python Software Foundation>" with subject "[Action Required] Affirm your PSF Membership voting status"

Why you are being asked to do this:

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

The PSF has not enforced this in the past, because it was technically challenging to do so. Now that our voting membership has been completely consolidated into psfmember.org, we are able to do so.

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 and increasing number of Contributing, Managing, and Fellow members with indefinite membership do not engage with our annual election, making quorum difficult to reach.

You can see your membership record and status on psfmember.org (note you must be logged in to view that page). If you are a voting-eligible member and do not already have a login there, please sign up and then email psf-donations@python.org so we can link your membership to your account. You can click the emailed link to re-certify without signing in. But please create your account and ensure it is linked to your membership so that we can ensure we have the most up-to-date contact information for you in the future.

What happens next? You’ll get an email from OpaVote with a ballot on or before June 20th and then you can vote!

Learn more about membership here or if you have questions about membership or nominations please email psf-elections@python.org In addition to Slack you are welcome to join the discussion about the PSF Board election on our forum.

Thinking about running for the Python Software Foundation Board of Directors? Let’s talk!

2023-05-31T15:22:00.001-04:00

This year’s Board Election Nomination period is opening tomorrow. Current board members want to share what being on the board is like and are making themselves available to answer all your questions about responsibilities, activities and time commitments via online chat. Please come join us on Slack anytime in June to talk with us about being on the PSF board.

Board Election Timeline:

Nominations are open, Thursday, June 1st, 2:00 pm UTC
Board Director Nomination cut-off: Thursday, June 15, 11:59 pm UTC
Voter application cut-off date: Thursday, June 15, 11:59 pm UTC
Announce candidates: Friday, June 16th
Voting start date: Tuesday, June 20, 12:01 am UTC
Voting end date: Friday, June 30, 11:59 pm UTC

Not sure what UTC is for you locally? Check here!

Nominations will be accepted here. (Note: you will need to sign into or create your python.org user account first). Learn more about membership here or if you have questions about membership or nominations please email psf-elections@python.orgIn addition to Slack you are welcome to join the discussion about the PSF Board election on our forum.

Also, you can see your membership record and status on psfmember.org. If you are a voting-eligible member and do not already have a login there, please sign up and then email psf-donations@python.org so we can link your membership to your account.

The Python Language Summit 2023: Towards Native Profiling for Python

2023-05-29T12:34:00.003-04:00

Joannah Nanjekye came to the Python Language Summit 2023 to discuss innovations by Scalene, a sampling-based Python profiler that can distinguish between native code and Python code in its reports. After its initial release in late 2019, Scalene has become one of the most popular Python profiling tools. It has now been downloaded 500,000 times from PyPI.

The Scalene project logo

A profiler is a tool that can monitor a program as it is running. Once the program has run, the profiler can provide a report analysing which lines of code were visited most often, which were the most expensive in terms of time spent, and which were the most expensive in terms of memory usage. Profilers can therefore be hugely useful tools for addressing performance issues in code. If you’re unsure where your program is spending most of its time, it can be hard to optimise it.

Profilers can be split into two broad categories: trace-based profilers and sampling-based profilers. Trace-based profilers work by intercepting each function call as your program is running and logging information about the time spent, memory usage, etc. Sampling-based profilers, meanwhile, take snapshots of your program at periodic intervals to monitor these things. A trace-based profiler has the advantage that it can provide a granular and precise level of detail about which lines of code were executed and when each function call finishes; this makes it ideal for use as a tool to monitor test coverage, for example. However, injecting tracing hooks into each function call can sometimes slow down a program and distort the analysis of where most time was spent. As a result, sampling-based profilers are sometimes preferred for profiling performance.

Scalene is a sampling-based profiler, and aims to address the shortcomings of previous sampling-based profilers for Python. One of the key challenges sampling-based profilers have faced in the past has been accurately measuring the time Python programs spend in “native code”.

Slide from Nanjekye’s talk, illustrating sampling-based profiling

Handling the problem of native code

“Native code”, also sometimes referred to as “machine code”, refers to code consisting of low-level instructions that can be interpreted directly by the hardware processor. Using extensions to Python written in C, C++ or Rust that will compile to native code – such as NumPy, scikit-learn, and TensorFlow – can lead to dramatic speedups for a program written in Python.

It also, however, makes life difficult for sampling-based profilers. Samplers often use Python’s signal module as a way of knowing when to take a periodic snapshot of a program as it is running. However, due to the way the signal module works, no signalling events will be delivered while a Python program is spending time in a function that has been compiled to native code via an extension module. The upshot of this is that sample-based profilers are often “flying blind” for Python code that makes extensive use of C extensions, and will sometimes erroneously report that no time at all was spent executing native code, even if the program in fact spent the majority of its time there.

Scalene’s solution to this problem is to monitor delays in signal delivery. It uses this information to deduce the amount of time that the program spent outside CPython’s main interpreter loop (due to the use of native, compiled code from an extension module). Further details on Scalene’s methods, and comparisons with other leading Python profilers, can be found in a recent paper by Emery D. Berger, Sam Stern and Juan Altmayer Pizzorno, “Triangulating Python Performance Issues with Scalene”.

Nanjekye also detailed Scalene’s sophisticated approach to measuring performance in child threads. Signal-based profilers often struggle with multi-threaded code, as signals can only be delivered and received from the main thread in Python. Scalene’s solution is to monkey-patch functions that might block the main thread, and add timeouts to these functions. This allows signals to be delivered even in multithreaded code.

Discussion

Nanjekye asked attendees at the Language Summit if they would be interested in integrating Scalene's ideas into the standard library's cProfile module, which was met with a somewhat muted response.

Pablo Galindo Salgado, a leading contributor to the Memray profiler, criticised Scalene’s signal-based approach, arguing it relied on inherently brittle monkey-patching of the standard library. It also reported unreliable timings, Salgado said: for example, if code in a C extension checks for signals to support CTRL-C, the resulting delays measured by Scalene will be distorted.

Salgado argued that integration with the perf profiler, which Python is introducing support for in Python 3.12, would be a better option for users. Mark Shannon, however, argued that perf distorted the execution time of Python programs; Salgado responded that Scalene did as well, as the use of signals came with its own overhead.

Nanjekye argued that the huge popularity of Scalene in the Python ecosystem was evidence that it had proved its worth. Carol Willing concurred, noting that Scalene was an especially useful tool with code that made heavy use of libraries such as NumPy, Scikit-Learn and PyTorch.

The Python Language Summit 2023: Burnout is Real

2023-05-29T12:21:00.002-04:00

Guido van Rossum, creator of the Python programming language, spoke at the 2023 Python Language Summit on the subject of open-source burnout, strategies for tackling it, and how to avoid it.

The first known case of burnout in the field of open-source software, van Rossum speculated, may have been Charles Babbage, who gave up the post of Lucasian Professor of Mathematics (the “Chair of Newton”) at Cambridge University in 1839.

“In 1839 the demands of the Analytical Engine upon my attention had become so incessant and so exhausting, that even the few duties of the Lucasian Chair had a sensible effect in impairing my bodily strength. I therefore sent in my resignation.”

-- Charles Babbage, “Passages from the Life of a Philosopher” (Chapter 4)

Van Rossum described how the Python community had been hit multiple times by core developers, suffering from burnout, suddenly disappearing for extended periods of time. Van Rossum told the story of one core developer, previously one of the most prolific contributors to CPython, who had abruptly ceased contributing around a decade ago. He had hardly been heard from since.

Van Rossum himself, he recounted, had felt so burned out by the acrimonious debate around PEP 572 (proposing the “walrus operator”, :=), that it led to him stepping down from his post as Benevolent Dictator For Life (“BDFL”) of Python in 2018. Decisions about the language were ceded to a democratically elected Steering Council, which has governed Python ever since.

Burnout, van Rossum noted, was often connected to conflict – and it often didn’t matter whether or not you ended the conflict victorious. Merely having the conflict at all could be exhausting.

Van Rossum’s talk itself was fairly short, but was followed by a lengthy discussion among the assembled core developers on the experiences they’d had with burnout, and strategies that could be employed to tackle it.

Several attendees in the room commented that learning to recognise burnout in yourself was an important skill. Some participants in the discussion described times when they had suddenly realised that things that had previously been enjoyable had morphed into a source of stress. One core developer told the story of a conference they had organised, at which they had felt such extreme stress that they were unable to think of any of the things that had gone well. Instead, they found themselves fixated on all of the minor things that had gone wrong.

Learning to recognise burnout in others was perhaps an even harder problem to solve. Van Rossum noted that the developers most susceptible to burnout were generally those who were most active and engaged with the community. But how can you distinguish between somebody devoting their time to CPython because of the intense enjoyment they found in contributing to the project, somebody who might have formed an unhealthy addiction to open source, and somebody who was only continuing to contribute out of a misplaced sense of obligation?

Some developers spoke of strategies they used to decompress. Brett Cannon described how he periodically takes “open source breaks”, in which he forces himself to spend a period of time without looking at his GitHub notifications or thinking about his open-source commitments. Mariatta Wijaya spoke about how she found mentoring other Python programmers to be deeply healing. All agreed that it was crucial to talk to friends and relatives when you were feeling close to burnout.

It was agreed that the Python community needed to do better in many ways. We needed to become better, as a community, at understanding when other people said that they were unable to complete something they had previously committed to. And perhaps we needed to normalise questions such as, “Hey, you’ve been super productive and responsive for too long. When do you think you’ll burn out?”

Russell Keith-Magee remarked that systems with single points of failure were bound to lead to situations of intense stress. These systems would inevitably, at some point, fail. The transition from a single BDFL (with an indefinite term) to a five-member Steering Council with one-year terms had been a very positive change in that regard, Keith-Magee said. But there were still places in CPython development where there were single points of failure. Examples included various esoteric platforms where support from CPython depended on a single core developer being able to give up their time to review PRs relating to the platform.

Carol Willing agreed with Keith-Magee, pointing out that no matter who you were, you were rarely the only person who could do a certain task. You might be the person who could do it fastest or best – but sometimes, it was important to “see the people, and share the joy”.

Łukasz Langa spoke about his role as part of the current Code of Conduct Working Group, to which any violations of the Python Code of Conduct can be reported. Langa remarked that being part of the Working Group had brought to the fore parts of the community which he had previously been mostly unaware of. He encouraged everybody in the room to report toxic members of the community who were discouraging or aggressive online.

Speaking personally, for a moment: I tried to take an open-source break earlier this year, when I felt myself close to burning out on some of my open-source commitments. I can’t say it was fully successful – my addiction to GitHub was too great for me to resist glancing at my notifications occasionally. But it was helpful, and re-energising, to spend some time doing a creative activity that bore with it a 0% risk of people shouting at me on the internet about it:

The Python Language Summit 2023: Making the Global Interpreter Lock Optional

2023-05-29T12:18:00.002-04:00

The Global Interpreter Lock (“GIL”), is one of the most fundamental parts of how Python works today. It’s also one of the most controversial parts, as it prevents true concurrency between threads – another way of saying that it’s difficult to run two functions simultaneously while writing pure-Python code.

If there’s one blog that really “took off” after I wrote last year’s coverage on the Python Language Summit, it was my blog on Sam Gross’s proposal to make Python’s Global Interpreter Lock (the “GIL”) optional. One week following the publication of my articles, the blog had been viewed nearly 38,000 times; the blog in “second place” had only been viewed 5,300 times.

Interest in removing the GIL is clear, therefore – and this year, Gross returned to the Python Language Summit to discuss the development of his plans.

Dare to dream of a GIL-free world

Gross started off by giving an update on how work on nogil – Gross’s fork of CPython with the GIL removed – had progressed over the past year. Gross had been spending the last few months rebasing his fork onto CPython 3.12. As a result, he was now able to give an accurate estimate of how bad the performance costs to single-threaded code would be, if the GIL were removed.

Over the past year, Gross had also written a PEP – PEP 703 – which, following the Language Summit, was submitted to the Steering Council for their consideration on May 12. If the PEP is accepted by the Steering Council, a version of Python with the GIL disabled could be available as soon as Python 3.13. (To discuss the ideas in the PEP, head to the thread on discuss.python.org.)

Gross reported that the latest version of nogil was around 6% slower on single-threaded code than the CPython main branch, and that he was confident that the performance overhead could be reduced even further, possibly to nearly 0%. Most of the overhead was due to reference counting and changes that had been required to the operation of CPython’s new-in-3.11 specialising adaptive interpreter. With multiple threads, the performance overhead was around 8%.

A slide from Gross's talk
(numbers indicate the per-thread overhead)

Having rebased onto Python 3.12, Gross was also able to give an estimate on the extent of the code changes that would be required to CPython, were nogil to be accepted. Excluding generated files, Gross reported that around 15,000 lines of code would need to be changed. There would also need to be some alterations to mimalloc, which nogil depends on – but Gross was hopeful that these would be accepted to mimalloc itself, reducing the need for CPython to maintain mimalloc patches in its codebase.

Some audience members expressed concern about the prospect of “#ifdef hell” across the code base, to account for the two possible CPython build options. However, Gross countered that most of the changes required could be made unconditionally without resorting to #ifdefs, since the changes were simply no-ops with the GIL enabled.

The plan for nogil remains that it would be enabled via a compile-time flag, named --disable-gil. Third-party C extensions would need to provide separate wheels for GIL-disabled Python.

GIL gotta go

Last year, it felt as though Gross’s proposal was met with a certain degree of excitement, but also a certain degree of scepticism. It was thrilling to see how far nogil had come, but there was a certain amount of frustration in the room at the lack of a concrete plan for where to go next.

This year, it felt like the proposal was greeted much more warmly. Gross had come to the summit with a far more clearly defined roadmap for how we might get to nogil, and had taken the time to put together detailed estimates of the performance impact and the extent of the code changes.

“Thank you for doing this… now we have something we can actually consider!”

-- Brandt Bucher, CPython Core Developer

Attendees at the Language Summit were also impressed at how low the performance overhead of nogil was, although Mark Shannon commented that he thought the numbers might be “a slight underestimate”. Gross explained that he had managed to achieve a 2-3% speedup by optimising for the case where only a single thread was active. Even in multithreaded programs, he explained, this provided a performance boost, since even in multithreaded code, it was often the case that only a single thread would be attempting to access an object at any given point in time.

Larry Hastings expressed concern that nogil might make debugging code harder; Gross responded that there was some impact on debuggability, but that it wasn’t too bad, in his opinion. Pablo Galindo Salgado, release manager for Python 3.10 and 3.11, expressed concern that nogil could also make implementing debuggers trickier – but commented that “it might be worth the price” anyway.

Another point of discussion was the changes Gross had made to the specialising adaptive interpreter in the nogil fork. In order for the specialisations to work with the GIL disabled, Gross had had to guard the adaptive specialisations to the bytecode behind a lock. As well as this, each thread had been limited to a single specialisation of any given bytecode; with the GIL enabled, the adaptive interpreter can respecialise bytecode multiple times. Gross commented that he thought it would probably be possible to allow multiple specialisations of bytecode in multithreaded code, but that this would require further investigation. His current solution was the simplest one he had found, for now.

The Python Language Summit 2023: Three Talks on the C API

2023-05-29T12:13:00.002-04:00

The Python Language Summit 2023 began with an extended discussion of Python’s C API – the interface through which it is possible to communicate between code written in Python and code written in low-level languages, like C. The fullness of this interface is a significant factor behind the vibrancy of Python’s ecosystem, enabling libraries such as NumPy and pandas that are foundational to Python’s widespread use in data science.

Three speakers had booked slots to discuss the C API this year: Mark Shannon, Guido van Rossum, and Antonio Cuni. The conversation evolved naturally from one talk to the next, so in this blog post, I’ll be discussing the three talks together.

All at sea on the C API

The C API at sea (illustration by DALL-E)

“I still don’t know what the C-API is, and I’ve been trying for years!”

-- Mark Shannon, CPython Core Developer

Mark Shannon spoke on the problems (as he saw them) with Python’s C API. Shannon lamented that with every minor Python version, a slew of third-party C extensions seemed to break. He argued that the root cause was that the needs of C extensions were not adequately met by the formal C API, which had evolved in a haphazard and often-unplanned way over the past three decades of Python’s existence.

As a result of the C API’s flaws, Shannon said, extension authors were forced to reach beyond the formal API and into implementation details that had emerged as a kind of “implicit API”. The implementation details that constituted the new “implicit API” had become so widely depended upon that it was now impossible for CPython to change some parts of its code without breaking large parts of the Python ecosystem.

Shannon believes that the new “implicit API” should be formalised in Python 3.13. This, he argues, would put an end to the cycle of CPython releases inevitably leading to widespread breakages in C extensions.

Sam Gross, who (among other things) has contributed to pytorch, agreed with Shannon that the C API was lacking in many areas. Gross argued that there was a great deal of important functionality that wasn’t exposed to extension authors. “Projects just end up copying-and-pasting CPython C code,” Gross said, meaning the extensions broke with each new release of CPython.

Pablo Galindo Salgado, release manager for Python 3.10 and 3.11, said that the release process for those versions had felt like a “game of whackamole” when it came to third-party C extensions breaking. Salgado argued that CPython needed to reach out to the authors of extensions such as pytorch to gather detailed feedback on what core functionality was missing from the API. Several attendees expressed frustration with a perceived tendency among C extension authors to immediately reach into CPython implementation details when something they needed was missing from the API. The result of this was that CPython core developers were often in the dark about which things the C API should be providing, but currently wasn’t. “We might not be able to give you a solution,” Salgado said, “But please come to us and tell us what your problem is, if you have a problem!”

Gross proposed that CPython should run third-party test suites with new versions of CPython as they were being developed, so that the Core Dev team would be able to spot third-party breakages early and gauge the impact of their changes. Pytorch operated a similar programme, Gross said, and it had been successful in helping to limit breakages of third-party pytorch models as the core pytorch team evolved their API.

Brandt Bucher noted, however, that the problem often wasn’t so much that CPython was unaware when they were breaking third-party code – the benchmarks run in the pyperformance suite often served as an early warning signal for breakages in C extensions. The problem was often that CPython would offer to help affected projects, only to have their help rejected. Several core developers had previously sent pull requests to help third-party projects become compatible with an upcoming version of CPython, only for their pull requests to remain unmerged for several months due to burned-out maintainers of these projects.

Let’s get specific

Guido van Rossum speaks to the Language Summit on the C API
(photo by Hugo van Kemenade)

Shannon was clear about what he thought the problem with the C API was. The problem was that the C API was insufficient for the authors of C extensions, leading these authors to reach into CPython implementation details, leading to an unending cycle of projects breaking with each new release of CPython. Others, however, argued that this wasn’t so much a specific problem but a genre of problems. Each specific project might have a different notion about which things were imperfect with the C API, and which things were missing from the C API. Each imperfection or absence could be considered a concrete problem in its own way. “Things break for everybody, but things break in different ways for different people,” Carol Willing argued. “We need more granularity in our understanding of that.”

As Mark Shannon’s slot drew to an end, Guido van Rossum opted to continue the discussion that Shannon had started, but sought to draw attention to a more precise enumeration of the difficulties C API users were facing.

“There’s lots of ideas here, but I don’t know what the problem is!”

-- Carol Willing, CPython Core Developer

Simon Cross, a contributor to the HPy project, reported that the HPy project had, in the early stages of the project, put together a long list of the problems, as they saw them, with the CPython C API. Cross offered to share the list with the Core Dev team. Thomas Wouters, a Google employee, also offered to provide a list of difficulties Google had experienced when upgrading to recent Python releases, something the company keeps detailed records of. There was agreement that putting together a comprehensive list of problems with the existing API was an important first step, before CPython could consider drawing up plans to fix the problem.

The C API discussions ended with an agreement that further discussion was required. Interested parties can follow the ongoing conversation at https://github.com/capi-workgroup/problems/issues. The plan is to work towards an informational PEP, with input from an array of stakeholders, outlining a consensus around the problems and pitfalls in the current C API. Once the problems with the status quo have been enumerated in detail, the community might be in a position to consider possible solutions.

HPy: A possible solution?

A slide from Antonio Cuni's talk on HPy

While the C API discussions ended with a detailed discussion of the problems in the current C API, the first talk of the day was in fact by Antonio Cuni, a core developer with the HPy project. HPy is an alternative C API for Python – an API that seeks to avoid many of the pitfalls of the current API. The contention of the HPy developers is that the current C API is bad for CPython, bad for alternative implementations of Python such as PyPy or GraalPython, and, ultimately, bad for end users.

HPy is a specification of a new API and ABI for extending Python that is Python implementation agnostic and designed to hide and abstract internal details

-- The HPy GitHub README

Cuni began by describing the key goals of the HPy project:

An API that doesn’t leak CPython-specific implementation details
A 0% (or close to 0%) performance overhead when compared with CPython’s current C API
A “Universal ABI” that allows compiled extension modules to use the same interface to communicate with PyPy (for example) as they would do to communicate with CPython
An API that is garbage-collection friendly.

Cuni argued that if the Python ecosystem as a whole moved to using HPy, instead of the “official” C API, there would be dramatically fewer breakages of C extensions with each new Python release. Cuni’s proposal was that CPython should “officially bless” HPy as the recommended C API for Python.

HPy Hpy Hooray?

Simon Cross, HPy Core Developer
(photo by Hugo van Kemenade)

Cuni’s talk was exuberant, but it was at times somewhat unclear what exactly he was asking for from the room. “The investment from CPython,” Cuni argued “would be a political investment rather than a technical one”. Thomas Wouters, however, argued that the CPython team didn’t have the “moral authority” to coerce extension authors into using HPy. Hynek Schlawack agreed, arguing that it was perhaps unrealistic to migrate the entire Python ecosystem towards HPy.

Many were uncertain about what it would even mean to “officially bless” HPy – would CPython host HPy’s documentation on docs.python.org? Or would CPython simply add a note to the documentation of the C API that the “official” C API was no longer the recommended way to write a C extension? Guido van Rossum emphasised that a top-down approach from the Core Dev team to extension authors wouldn’t work: nobody wanted a repeat of the decade-long transition from Python 2 to Python 3. Carol Willing agreed that pushing C extension authors to use HPy could be counterproductive, arguing that it was important to remember the impact of our decisions on end users of Python.

Other core developers were sceptical about the fundamentals of HPy itself. HPy’s origin story lies in difficulties PyPy encountered when it trying to use CPython’s existing C API. These difficulties led to attempts to create an API that could be easily used on either Python implementation. Larry Hastings argued that blessing an API that was friendlier to PyPy had clear benefits to PyPy (and other implementations), but that it was less clear where CPython stood to gain from this change.

Cuni’s response was that if the ecosystem migrated to an API that exposed fewer implementation details directly, CPython would be able to refactor its internal implementation far more seamlessly, as CPython would no longer have to worry about breaking a multitude of third-party C extensions with every internal reorganisation of code. Cuni mentioned efforts to run CPython using WebAssembly as a specific area where CPython could stand to gain, as the HPy API could interact far more easily with the Javascript garbage collector. And Cuni also noted that HPy made it easy for extension authors to test whether they were sticking to the API or not, something which is famously hard to know with the current C API. “We don’t know all the experimentation that this might enable,” Cuni exclaimed, however, “Because we haven’t implemented this change yet!”

Mark Shannon was another core developer expressing scepticism about HPy. Shannon argued that while HPy had strengths over the “official” C API, it was far from perfect. “We should try to fix CPython’s API” before CPython recommended users switch to HPy, Shannon argued. Simon Cross, also of the HPy project, said that the team welcomed feedback about where they could improve. It was still easy for HPy to make changes, Cross argued, given they had not yet achieved widespread adoption.

Python Software Foundation News

Announcing Python Software Foundation Fellow Members for Q3 2023! 🎉

Announcing the Deputy Developer in Residence and the Supporting Developer in Residence

EU’s Cyber Resilience Act Passes with Wins for Open Source

Announcing the Hidden Figures of Python Podcast!

It's time for our annual year-end PSF fundraiser and membership drive 🎉

Support Python in 2023!

There are two ways to join in the drive this year:

Let’s take a look back on 2023:

Our Thanks:

The Python Sofware Foundation receives the Wonderfully Welcoming Award from GitHub!

Join the Python Developers Survey 2023: Share and learn about the community!

Announcing our new Community Communications Manager!

September & October Board Votes

Security Developer-in-Residence 2023 Q3 Report

The Python Software Foundation authorized as a CVE Numbering Authority (CNA)

CPython vulnerability advisories available in Open Source Vulnerability database

Python Security Response Team

OpenSSF Day Europe 2023

Sigstore signatures for Python release artifacts

Adoption of system trust stores via Truststore

Future Projects and Challenges

Software Bills-of-Materials for CPython

Tracking bundled dependencies in Python packages

CPython and pip release process improvements

Python Developers Survey Numbers for 2022!

Announcing Python Software Foundation Fellow Members for Q2 2023! 🎉

The Python Software Foundation has been authorized by the CVE Program as a CVE Numbering Authority (CNA)

Announcing Our New PyPI Safety & Security Engineer!

Announcing Python Software Foundation Fellow Members for Q1 2023! 🎉

Announcing the 2023 PSF Board Election Results!

Announcing Our New Security Developer in Residence!

The 2023 PSF Board Election is Open!

Board Candidates for 2023 are Announced!

Affirming your PSF Membership voting status

Thinking about running for the Python Software Foundation Board of Directors? Let’s talk!

The Python Language Summit 2023: Towards Native Profiling for Python

Handling the problem of native code

Discussion

The Python Language Summit 2023: Burnout is Real

The Python Language Summit 2023: Making the Global Interpreter Lock Optional

Dare to dream of a GIL-free world

GIL gotta go

The Python Language Summit 2023: Three Talks on the C API

All at sea on the C API

Let’s get specific

HPy: A possible solution?

HPy Hpy Hooray?

Further Reading on HPy