Python Software Foundation News

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

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

Support Python in 2023!

For the fifth year in a row, the PSF is partnering with JetBrains on our end-of-year fundraiser. Over that time, the partnership has raised a total of over $95,000. Amazing! Thank you, JetBrains, for all your support.

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

Save on PyCharm! JetBrains is once again supporting the PSF by providing a 30% discount on PyCharm and all proceeds will go to the PSF! You can take advantage of this discount by clicking the button on the page linked here, and the discount will be automatically applied when you check out. The promotion will only be available through November 27th, so go grab the deal today!

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 all three? 🥳

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.

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

The Python Language Summit 2023: Python on Mobile

2023-05-29T11:34:00.002-04:00

At the Python Language Summit 2023, Russell Keith-Magee presented on the ongoing efforts of BeeWare, a project that aims to make it easier to run Python on mobile platforms such as Android and iOS.

The BeeWare logo

Russell Keith-Magee is one busy bee

Improving Python’s story for running on mobile has been a labour of love for Keith-Magee for eight years at this point. Keith-Magee last presented at the Python Language Summit in 2020 (a year when the summit was conducted entirely virtually due to the Covid-19 pandemic). Since then, however, great progress has been made.

The biggest change since his last update, Keith-Magee reported, wasn’t technical – it was financial. For the last year, BeeWare has no longer been a hobby project for Keith-Magee. He is now paid by Anaconda to work on the project full time, along with a colleague, Malcolm Smith. “I now have the resources to do the work” required to make this happen, he announced.

Keith-Magee came to the Language Summit this year with a proposal: to add Android and iOS as platforms with “tier-3” support from CPython in Python 3.13.

What does “tier-3 support” mean? Tier-3 support, as defined by PEP 11, describes a level of support that the CPython core developers commit to giving a specific platform. The CPython test suite is run constantly on popular platforms such as Ubuntu, Windows and MacOS, and test failures on these platforms can block releases until they are fixed. More esoteric platforms, meanwhile, are tested in CI less frequently. Test failures on those platforms will not necessarily block a release of CPython.

Tier-3 support is the current level of support Python provides to the emscripten, WASI and FreeBSD platforms, among others. If a platform has tier-3 support, the test suite will be run on the platform on a regular basis, but not on every pull request. Tier-3 support indicates that at least one core developer has committed to supporting CPython on that platform as best they can. However, test failures on that platform will not block a release of CPython.

The path to tier-3 support

Historically, a significant barrier standing in the way of mobile-platform support from CPython has been the difficulties associated with running tests on mobile platforms in CI. Keith-Magee announced, however, that it was now possible to run the CPython test suite on mobile platforms via Briefcase, BeeWare’s packaging and development tool. (Getting the test suite to pass is another issue – But Keith-Magee felt confident that it would be easy to make progress on that front.) As such, Keith-Magee reported, it should be feasible for CPython to integrate running tests on these platforms into the project’s testing infrastructure on GitHub.

One remaining issue is a fairly specific question, but an important one nonetheless: on a mobile platform, what should sys.platform be? The two major mobile platforms are currently inconsistent about this: on iOS, sys.platform == "ios", whereas on Android, sys.platform == "linux".

The advantage of the first approach is that it is easy for user code to detect whether the code is being run on iOS or not. The advantage of the second approach, meanwhile, is that most existing Python code won’t necessarily account for the possibility that it might be run on Android or iOS, so will run into difficulties with idioms such as the following:


if sys.platform == "linux":
    do_fancy_linux_only_feature()

The Android platform, Keith-Magee noted, is very similar to Linux, so by setting sys.platform to “linux”, a lot of code “just works” on Android even though the code hasn’t explicitly accounted for the possibility that it might be run on that platform.

Abuzz with excitement

Keith-Magee in flight (photo by Hugo van Kemenade)

Keith-Magee’s talk was greeted enthusiastically by the core developers in the room; there was strong consensus that Python needed a better story on mobile platforms. Carol Willing expressed excitement about the ways in which support for mobile platforms could help Python spread globally, to countries where large numbers of people had no access to desktop computers (but had easy access to phones). Łukasz Langa agreed, noting that he had received many enquiries about Python on mobile after giving a talk on the subject about a year ago. “It’s interesting to a lot of people,” Langa commented. “We need it.”

“Wooooo!”

-- Carol Willing, CPython Core Developer

On the sys.platform question, Core Developer Filipe Laíns said that he was working on a new API for the sysconfig standard-library module, which will provide a more granular way of distinguishing between platforms from user code. In the meantime, Brett Cannon wondered if BeeWare could use the same approach as CPython builds for WebAssembly: on WebAssembly builds, unusually, sys.platform has a different value to os.name (sys.platform is either "wasi" or "emscripten", but os.name is "linux").

Another outstanding question, however, is what the release process would look like for these new platforms. There was appreciation of the work Keith-Magee had already put into BeeWare, and nobody doubted that he would continue to be committed to the project. However, Keith-Magee is not currently a core developer, leading to a concern that CPython might be supporting a platform that nobody on the core team had expertise in.

Ned Deily, release manager for Python 3.6 and 3.7, worried that distributing CPython binaries for these platforms might not be feasible, as it would make the release process “even more arduous”. Keith-Magee responded that it could be possible to automate the build process for these platforms. If it wasn’t, he said, it also wouldn’t necessarily be essential for CPython to distribute official binaries for these platforms, at least at first.

Where next for BeeWare?

Keith-Magee’s next steps are to work towards upstreaming the patches to CPython that the BeeWare project has made, so that CPython on mobile platforms can “just work” without any changes being made. The alterations that have already been made to support CPython on WebAssembly have made this task much easier, Keith-Magee noted.

The Python Language Summit 2023

2023-05-29T11:14:00.011-04:00

Every year, just before the start of PyCon US, core developers, triagers, and special guests gather for the Python Language Summit: an all-day event of talks where the future direction of Python is discussed. The Language Summit 2023 included three back-to-back talks on the C API, an update on work towards making the Global Interpreter Lock optional, and a discussion on how to tackle burnout in the community.

This year's summit received around 45 attendees, and the summit was covered by Alex Waygood.

Attendees of the Python Language Summit

Three Talks on the C API: Talks by Antonio Cuni, Mark Shannon and Guido van Rossum
Making the Global Interpreter Lock Optional: A talk by Sam Gross
Towards Native Profiling for Python: A talk by Joannah Nanjekye
What is the stdlib for? A talk by Brett Cannon
Pattern Matching, __match__, and View Patterns: A talk by Michael Sullivan
Python on Mobile: State of the Union. A talk by Russell Keith-Magee
Burnout is Real: A talk by Guido van Rossum
Lightning Talks, featuring short presentations by Dong-hee Na, Carl Meyer and Amethyst Reese

The Python Language Summit 2023: Lightning Talks

2023-05-29T11:13:00.003-04:00

The Python Language Summit 2023 closed off with a trio of lightning talks from Dong-hee Na, Carl Meyer and Amethyst Reese.

Dong-hee Na: Let’s support LLVM-BOLT as an official feature

CPython Core Developer Dong-hee Na gave a short presentation on the LLVM-BOLT optimiser, arguing that we should support it as a standard feature of CPython.

LLVM-BOLT is a “post link time binary optimiser” that was adopted by the Pyston project, a performance-oriented fork of CPython 3.8. The Pyston team had reported that use of the optimiser resulted in performance gains of 2-4% on their benchmarks, although the Faster CPython team and Dong-hee Na had reported smaller returns when they had applied the optimiser to Python 3.11.

Dong-hee Na showed benchmark results that showed significant speedups in some areas with LLVM-BOLT applied to Python 3.12, but noted that LLVM-BOLT also caused regressions in some other areas due to overly aggressive optimisations. He announced that he had added support for LLVM-BOLT to CPython as an optional compile-time flag, --enable-bolt, to allow experimentation with the feature.

A slide from Dong-hee Na's talk on LLVM-Bolt

Carl Meyer: Lazy Imports – the sequel

Carl Meyer instigated a short discussion on proposals to introduce a mechanism enabling lazy imports in Python. Following Meyer’s lightning talk on the same subject last year, Meyer – along with his colleague, Germán Méndez Bravo (who, according to Meyer, deserves “most of the credit”) – had written PEP 690, proposing a compile-time flag that would make imports in Python lazy by default. The PEP, however, was rejected by the Steering Council in December 2022, due to concern that the new flag would have created a split in the community between programmers who used Python with lazy imports enabled, and those who used Python with eager imports.

Meyer’s question to the audience was: where next for lazy imports? Was it worth modifying the proposal and trying again, or was the whole idea doomed? Meyer noted that the team at Instagram, where he worked, had seen start-up time improvements of 50-80%, and 40-90% reductions in memory usage, by adopting lazy imports in the fork of CPython they used for the Instagram web server.

Meyer floated a series of possible changes (some mutually exclusive) that could be made to the PEP. For each possible change, he asked if the change would make attendees more or less likely to support adding support for lazy imports to Python:

Explicit opt-in syntax marking a specific import as lazy (e.g. lazy import inspect).
A clear roadmap detailed in the PEP, outlining the timeframe in which it was expected that lazy-import behaviour would become the default in Python.
A promise that the implementation of lazy imports would not lead to any changes being made to the dict data structure.
Generalised support of “lazy names”, rather than just support for lazy imports specifically.

The room unanimously agreed that change (3) would make them more likely to support the PEP, and largely agreed that change (4) would make them less likely to support it. The room was (frustratingly, for Meyer) split on whether proposals (1) and (2) would make them more or less likely to give the PEP their support.

On the bright side, only one attendee said they thought they could never support a proposal for lazy imports in Python. Unfortunately for Meyer, the attendee in question was Thomas Wouters, currently serving on the Steering Council.

Amethyst Reese: Can we `call` modules?

Amethyst Reese presented on an idea that has since become PEP 713: a proposal to add a mechanism allowing developers to easily create callable modules.

Amethyst Reese at the Python Language Summit
(Photo by Hugo van Kemenade)

Strictly speaking, it’s possible to create a callable module today, but it’s not exactly easy. The example given in the PEP looks something like the following:


import sys
import types

def fancy(...):
    ...

class FancyModule(types.ModuleType):
    def __call__(self, ...):
        return fancy(...)

sys.modules[__name__].__class__ = FancyModule

Reese proposes that we provide a simpler mechanism to create callable modules: simply provide special recognition for module-level __call__ functions, similar to the way that PEP 562 added special recognition of module-level __getattr__ and __dir__ functions. With the semantics specified in PEP 713, fancy.py could be rewritten as follows:


def fancy(...):
    ...

__call__ = fancy

With a module, fancy.py, defined like the above, users would simply be able to do the following:


import fancy
fancy()

This would allow users of Python to avoid constructs which often feel unnecessarily verbose and involve frustrating amounts of boilerplate, such as:


import datetime
import pprint
import dis

d = datetime.datetime()
pprint.pprint(...)
dis.dis(...)

It would also allow users to create callable modules in a way that would be easier for type checkers to support, as dynamically inserting custom objects into sys.modules can cause issues for these tools.

The proposal was met with curiosity by attendees of the Language Summit. Thomas Wouters said that he had originally opposed the addition of module-level __getattr__ and __dir__, introduced by PEP 562. However, now they had been introduced to Python, he was of the opinion that it might make sense to add support for module-level dunder methods including __call__, but also others such as __setattr__.

The Python Language Summit 2023: What is the Standard Library for?

2023-05-29T11:10:00.005-04:00

Brett Cannon came to the Python Language Summit this year with a fundamental question for the assembled core developers: What is the standard library for?

According to a quick python -c "import sys; print(len(sys.stdlib_module_names))" call on my laptop, the standard library in Python 3.11 consists of 305 importable modules. Many of these are implementation details that, if you’re a good citizen, you really shouldn’t be importing – but the point stands that the Python standard library is perhaps now larger than it should be.

But the goal of his question, Cannon explained, wasn’t to decide which modules to get rid of. Instead, it was to create guidelines on when and why new modules should be accepted into the standard library.

"We need to audit the standard library, and not deprecate it, but decide which bits should probably not have been added if we had perfect hindsight.

-- Guido van Rossum, CPython Core Developer and former BDFL

Carol Willing agreed that the core dev team shouldn’t be looking to remove modules en masse, but should decide what kinds of modules they wanted to admit in the future. Łukasz Langa agreed, and pointed out that it was often hard removing modules even when we wanted to, due to the fact that “the standard library is a huge import cycle”.

Where do we go now?

Cannon himself put forward two possible answers to his question, before tossing it out to the audience:

The standard library should contain everything required to bootstrap an installer.
The standard library should make it easy for beginners to be able to write scripts without installing anything.

The conversation was free-flowing, but a common point of consensus among the attendees was that the standard library should focus on tools and utilities that allow users to write better Python code. Hynek Schlawack cited dataclasses as an example of a module that made writing classes much less painful, and generally led to them writing better code as a result. (Schlawack is the author of the attrs library, the third-party inspiration for dataclasses, which itself is still going strong.) Filipe Laíns agreed, arguing that the core dev team should focus on building business implementations for third-party libraries to build on top of.

“The default answer for ‘Should this be in the standard library?’ should be ‘No’, but we should bless smaller utilities that help people write better Python code”

-- Antonio Cuni, HPy Core Developer

There was a certain amount of regret in the air about modules that perhaps should never have been added to the standard library, and had proved themselves to be significant maintenance burdens in the years since, but could now never be removed. tkinter, it was universally agreed, was the primary example here; possibly multiprocessing also.

Guido van Rossum pondered whether asyncio should ever have been added to the standard library, remarking that it had been difficult to evolve asyncio while it was in the standard library, and had possibly been added before it was “fully baked”. The ssl integration had probably been a mistake, he said, and should have been left to third parties.

Łukasz Langa noted that modules such as asyncio and typing, which had continued to evolve rapidly after being added to the standard library, had helped spur new syntax changes to Python that had been to the language’s betterment. Without asyncio in the standard library, Langa argued, we would probably never have adopted the async/await syntax that is now the foundation of asynchronous Python programming.

Zac Hatfield-Dods, maintainer of several prominent third-party packages, said that different standard-library packages had different impacts on the Python ecosystem. Pytest, one of the libraries he maintains, had managed to flourish and find success despite the existence of unittest in the standard library. But another library he helps out with, the asynchronous Trio framework, had struggled to attract users while asyncio had been part of the standard library. “Nobody supports alternative async implementations,” he complained, despite Trio’s development often being years ahead of where asyncio is. (In the coffee break afterwards, Hatfield-Dods was keen to emphasise that he is, in fact, a fan of asyncio and the work of the asyncio maintainers.)

Zac Hatfield-Dods (left), speaking at the Language Summit
(Photo by Hugo van Kemenade)

Cannon brought up the question of whether a module like pathlib belonged. “It’s just sugar,” he remarked – i.e., hardly a “core utility” or a protocol that allowed people to write better code. But it has nonetheless been one of the more popular additions to the standard library in recent years. Langa again pushed back, arguing that without the addition of pathlib to the standard library, we would never have added os.PathLike, a protocol that had allowed a common interface for describing file-system paths in Python. “A third-party PyPI package wouldn’t have convinced us to make that change,” Langa argued.

Several attendees noted that adding a module to the standard library often made it hard for users to use features added to the module in newer versions of Python, due to CPython’s slow development cycle. One solution could be to provide third-party versions of standard-library modules on PyPI, backporting the latest features of a module to older versions of Python. Thomas Wouters argued that previous attempts at providing these backport modules had often been disastrous. However, Jelle Zijlstra noted that typing_extensions, which backports features from the latest version of the typing module, had been incredibly successful (though it was sometimes hard to maintain).

Overall, there was agreement that the original motivations for a large, “batteries-included” standard library no longer held up to scrutiny. “In the good old days,” Ned Deily reminisced, “We said ‘batteries-included’ because we didn’t have a good story for third-party installation.” But in 2023, installing third-party packages from PyPI is much easier.

Often, Thomas Wouters noted, people preferred using standard-library modules in a corporate setting due to the fact that the installation of any third-party package would require approval from their company’s IT department. But, he noted, this was hardly Python’s problem.

Python Software Foundation News

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

Support Python in 2023!

There are three 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

The Python Language Summit 2023: Python on Mobile

Russell Keith-Magee is one busy bee

The path to tier-3 support

Abuzz with excitement

Where next for BeeWare?

The Python Language Summit 2023

The Python Language Summit 2023: Lightning Talks

Dong-hee Na: Let’s support LLVM-BOLT as an official feature

Carl Meyer: Lazy Imports – the sequel

Amethyst Reese: Can we __call__ modules?

The Python Language Summit 2023: What is the Standard Library for?

Where do we go now?

Amethyst Reese: Can we `call` modules?