Notice of Python Software Foundation Bylaws change, effective 10 August 2024

There has been a lot of attention directed at our Bylaws over the last few weeks, and as a result of that conversation, the Board was alerted to a defect in our Bylaws that exposes the Foundation to an unbounded financial liability.

Specifically, Bylaws Article XIII as originally written compels the Python Software Foundation to extend indemnity coverage to individual Members (including our thousands of “Basic Members”) in certain cases, and to advance legal defense expenses to individual Members with surprisingly few restrictions.

Further, the Bylaws compel the Foundation to take out insurance to cover these requirements, however, insurance of this nature is not actually available to 501(c)(3) nonprofit corporations such as the Python Software Foundation to purchase, and thus it is impossible in practice to comply with this requirement.

In the unlikely but not impossible event of the Foundation being called upon to advance such expenses, the potential financial burden would be virtually unlimited, and there would be no recourse to insurance.

As this is an existential threat to the Foundation, the Board has agreed that it must immediately reduce the Foundation’s exposure, and has opted to exercise its ability to amend the Bylaws by a majority vote of the Board directors, rather than by putting it to a vote of the membership, as allowed by Bylaws Article XI.

Acting on legal advice, the full Board has voted unanimously to amend its Bylaws to no longer extend an offer to indemnify, advance legal expenses, or insure Members when they are not serving at the request of the Foundation. The amended Bylaws still allow for indemnification of a much smaller set of individuals acting on behalf of the PSF such as Board Members and officers, which is in line with standard nonprofit governance practices and for which we already hold appropriate insurance.

The full text of the changes can be viewed at https://github.com/python/psf-bylaws/compare/a35a607...298843b

These changes shall become effective on Saturday 10 August 2024, 15 days from the date of this notice.

Any questions about these changes may be sent to psf@python.org. We gladly welcome further suggestions or recommendations for future Bylaws amendments.

Thank you,

The PSF Board of Directors

Python’s Supportive and Welcoming Environment is Tightly Coupled to Its Progress

Python is as popular as it is today because we have gone above and beyond to make this a welcoming community. Being a friendly and supportive community is part of how we are perceived by the wider world and is integral to the wide popularity of Python. We won a “Wonderfully Welcoming Award” last year at GitHub Universe. Over and over again, the tech press refers to Python as a supportive community. We aren’t the fastest, the newest or the best-funded programming language, but we are the most welcoming and supportive. Our philosophy is a big part of why Python is a fantastic choice for not only new programmers, glue programmers, and folks who split their time between research and programming but for everyone who wants to be part of a welcoming community.

We believe to be “welcoming” means to do our best to provide all participants with a safe, civil, and respectful environment when they are engaging with our community - on our forums, at PyCon events, and other spaces that have committed to following our Code of Conduct. That kind of environment doesn’t happen by accident - a lot of people have worked hard over a long time to figure out the best ways to nurture this welcoming quality for the Python community. That work has included drafting and improving the Code of Conduct, crafting and implementing processes for enforcing it, and moderating the various online spaces where it applies. And most importantly the huge, collective effort of individuals across the community, each putting in consistent effort to show up in all the positive ways that make the Python community the warm and welcoming place that we know.

The recent slew of conversations, initially kicked off in response to a bylaws change proposal, has been pretty alienating for many members of our community. They haven’t all posted publicly to explain their feelings, but they have found other ways to let the PSF know how they are feeling.

• After the conversation on PSF-Vote had gotten pretty ugly, forty-five people out of ~1000 unsubscribed. (That list has since been put on announce-only)

• We received a lot of Code of Conduct reports or moderation requests about the PSF-vote mailing list and the discuss.python.org message board conversations. (Several reports have already been acted on or closed and the rest will be soon).

• PSF staff received private feedback that the blanket statements about “neurodiverse people”, the bizarre motives ascribed to the people in charge of the PSF and various volunteers and the sideways comments about the kinds of people making reports were also very off-putting.

As an open source code community, we do most things out in the open which is a fantastic strategy for code. (Many eyes, shallow bugs, etc.) We also try to be transparent about what is going on here at the Foundation and are always working to improve visibility into our policies, current resource levels, spending priorities and aspirations. Sometimes staff and volunteers are a little too busy “doing the work" to “talk about the work” but we do our best to be responsive, especially in the areas that people want to know more about. That said, sometimes things do need to be kept confidential, for privacy, legal, or other good reasons.

Some examples:

• Most Code of Conduct reports – Oftentimes, these reports have the potential to affect both the reporter and the reported person’s reputations and livelihoods so our practice is to keep them confidential when possible to protect everyone involved. Some of you have been here long enough to remember the incident at PyCon US in 2013, an example of the entire internet discussing a Code of Conduct violation that led to negative repercussions for everyone involved, but especially for the person who reported the behavior.

• Legal advice and proceedings – It is an unfortunate fact of the world that the legal system(s) we operate under sometimes require us to keep secret information we might otherwise prefer to disclose, often because doing so could open us up to liability in a way that would create significant risk to the PSF or it could potentially put us in violation of laws or regulation. It’s our responsibility to follow legal guidance about how to protect the Foundation, our resources, and our mission in these situations.

• Mental health, personal history, or disability status – Community members should not, for example, have to disclose their status as neurodivergent or share their history with abuse so that others can decide if they are allowed to be offended. Community members should also not be speculating about other individuals’ characteristics or experience in this regard.

We have a moral imperative – as one of the very best places to bring new people into tech and into open source – to keep being good at welcoming new people. If we do not rise and continue to rise every day to this task, then we are not fulfilling our own mission, “to support and facilitate the growth of a diverse and international community of Python programmers.” Technical skills are a game-changer for the people who acquire them and joining a vast global network of people with similar interests opens many doors. Behavior that contributes to a hostile environment around Python or throws up barriers and obstacles to those who would join the Python community must be addressed because it endangers what we have built here.

Part of the care-taking of a diverse community “where everyone feels welcome” sadly often means asking some people to leave – or at least take a break. This is known as the paradox of tolerance. We can not tolerate intolerance and we will not allow combative and aggressive behavior to ruin the experience in our spaces for everyone else. People do make honest mistakes and don’t always understand the impact that their words have had. All we ask is that as community members we all do our best to adhere to the Code of Conduct we’ve committed to as a community, and that we gracefully accept feedback when our efforts fall short. Sometimes that means learning that the words, assumptions or tone you’re using aren’t coming across the way you’ve intended. When a person’s words and actions repeatedly come in conflict with our community norms and cause harm, and that pattern hasn’t changed in response to feedback – then we have to ask people to take a break or as a last resort to leave the conversation.

Our forum, mailing lists and events will continue to be moderated. We want to thank everyone who contributed positively to the recent conversations and everyone who made the hard choice to write to us to point out off-putting, harmful, unwelcoming or offensive comments. We especially want to thank all the volunteers who serve on the Python Discourse moderation team and our Code of Conduct Working Group. We know it’s been a long couple of weeks, and although your work may occasionally be draining and unpleasant, it is also absolutely essential and endlessly appreciated by the vast majority of the community. Thank you for everything you do!


Sincerely,
Deb Nicholson
Dawn Wages
Tania Allard
KwonHan Bae
Kushal Das
Georgi Ker
Jannis Leidel
Cristián Maureira-Fredes
Christopher Neugebauer
Denny Perez
Cheuk Ting Ho
Simon Willison

PSF Board update on improvements to the PSF Grants program

In December 2023 we received an open letter from a coalition of organizers from the pan-African Python community asking the PSF to address concerns and frustrations around our Grants Program. The letter writers agreed to meet with us in December and January to go into more detail and share more context from the pan-African community. Since then, we have been doing a lot of listening and discussing how to better serve the community with the input that was offered.

The PSF Board takes the open letter from the pan-African delegation seriously, and we began to draft a plan to address everything in the letter. We also set up improved two-way communications so that we can continue the conversation with the community. The writers of the open letter have now met several times with members of the PSF board. We are thankful for their insight and guidance on how we can work together and be thoroughly and consistently supportive of the pan-African Python community.

We care a lot about building consensus and ensuring that we are promising solutions that have support and a realistic workflow. Building an achievable plan that meets the needs of the community has involved work for the PSF’s small staff. It also included additional conversations with and input from the volunteers who serve on the Board and in our working groups, especially the Grants Working Group. We are grateful for the input as well as the opportunity to improve.

Plans and progress on the Grants Program

Here is what’s already been done:

• Set up Grants Program Office Hours to open up a line of casual sustained communication between the community and our staff members who support the grants program. Several sessions have already taken place.
• The PSF contracted Carol Willing to do a retrospective on the DjangoCon Africa review and approval and make suggestions for improvements or changes. We published her report in March.
• We published a transparency report for our grants numbers from the last two years, and plan to publish a report on our grants work for every year going forward so we can continue to work in the open on continually improving the grants program.  
• In May, the board voted that we will not override or impose any country-specific human rights regulation for Python communities when deciding whether or not to fund community-run Python or Python-related events. The Grants Program will use the same criteria for all grant requests, no matter their country of origin. This does not affect our criteria for choosing a specific US state for PyCon US and it does not change our ability to fund events in countries that are sanctioned by the US government (where the PSF is based.) Finally, the Grants Working Group will still require a robust and enforceable code of conduct and we expect local organizers to choose what is appropriate for their local community when drafting their code of conduct.

What is on our roadmap:

• With community input, we’ll be overhauling the grant application process and requirements for applications. Our goal is to make the process inclusive and the administrative requirements as lightweight as possible, while not creating additional legal or administrative work.
• We’re conducting a thorough examination of our grant priorities by subject matter and location. We hope to make requesting and reviewing grants for activities beyond events easier.
• Continuing to reimagine the PSF Board’s responsibility within the community. Please read on for our thought process and work in this area.

Reevaluating PSF Board member communications and conduct norms and standards

We discussed Board member conduct and communications norms – both past and future – at our retreat in January. We realize that some things were said by past and current Board members that did not reflect the PSF’s outlook or values. We are working to ensure current and future Board members understand the power their communications have on our community. Understanding the expectations and responsibilities that come with service on the PSF Board is part of orientation for service. Going forward we plan to invest more time into this topic during our PSF Board orientations.

The Board has agreed to hold each other accountable and use the position of PSF Board member responsibly in communications with the community. We acknowledge that PSF Board members have not always recognized the impact that their comments have had on community members, either in private or in public. Going forward, community members can report board and board-delegated working group members’ conduct to individuals who do not serve on the board. Two members of the PSF’s Code of Conduct Working Group (Jeff Triplett (jeff.triplett@pyfound.org) and Tereza Iofciu (email is coming)) have volunteered to receive these reports and handle them separately. At a time that Jeff or Tereza are unable to receive these reports, other non-board members of the Code of Conduct working group will be nominated to manage such reports.

Moving forward together

Moving forward, the PSF Board and Staff will continue to prioritize transparency through the form of the Grants Office Hours and yearly reports. Our focus will move from response to charter, process, and documentation improvements based on the findings we have made. The PSF Board will continue to conduct annual orientations and ad hoc check-ins on our communication and conduct standards. We welcome you to send your questions, comments, and suggestions for the Grants Program to grants@pyfound.org.

As the great Maya Angelou has said, “Do the best you can until you know better. Then, when you know better, do better.” We want to thank the pan-African community for showing us that we can do better and we look forward to being a community partner that can be counted on to hear criticism and continually make changes that improve our service to the Python community.

Announcing the 2024 PSF Board Election & Proposed Bylaw Change Results!

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

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

Board Members Elect

Congratulations to our three new Board members who have been elected!

• Tania Allard
• KwonHan Bae
• Cristián Maureira-Fredes

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

PSF Bylaw Changes

All three of the proposed PSF Bylaw changes are approved:

• Merging Contributing and Managing member classes
• Simplifying the voter affirmation process by treating past voting activity as intent to continue voting
• Allow for removal of Fellows by a Board vote in response to Code of Conduct violations, removing the need for a vote of the membership

We appreciate the high level of engagement on the proposed Bylaw changes, and the range of perspectives and points that were raised. We hope that our efforts towards increased transparency, such as the Office Hour session, and our responses in the FAQ helped to continue to build trust with the community. Our goal with these changes continues to be:

• Making it simpler to qualify as a Member for Python-related volunteer work
• Making it easier to vote
• Allowing the Board more options to keep our membership safe and enforce the Code of Conduct

This announcement serves as notice that the Bylaws changes have been approved by the membership, and will automatically go into effect 15 days from now, on Thursday, August 1st, 2024.

Thank you!

We’d like to take this opportunity to thank our outgoing board member, Débora Azevedo, for her outstanding service. Débora served on the PSF Board through a particularly eventful time; bringing PyCon US into an age of hybrid events, responding to calls from our community for transparency, and hiring multiple new staff members to continue to improve our organization. Thank you for supporting the PSF and the Python community through so much change- you are appreciated!

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

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

What’s next?

If you’re interested in the complete tally, make sure to check the Python Software Foundation Board of Directors Election 2024 Results page. These results will be available until 10 Sep 2024 at 10:00 AM EDT.

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

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

Announcing Our New PyPI Support Specialist!

We are thrilled to announce that our first-ever search for a dedicated PyPI Support Specialist has concluded with the hire of Maria Ashna, the newest member of the Python Software Foundation (PSF) staff. Reporting to Ee Durbin, Director of Infrastructure, Maria joins us from a background in academic research, technical consulting, and theatre.

Maria will help the PSF to support one of our most critical services, the Python Package Index (PyPI). Over the past 23 years, PyPI has seen essentially exponential growth in traffic and users, relying for the most part on volunteers to support it. With the addition of requirements to keep all Python maintainers and users safe, our support load has outstretched our support resources for some time now. The Python Software Foundation committed to hiring to increase this capacity in April and we’re excited to have Maria on board to begin providing crucially needed support.

From Maria, “I am a firm believer in democratizing tech. The Open Source community is the lifeblood of such democratization, which is why I am excited to be part of PSF and to serve this community.”

As you see Maria around the PyPI support inbox, issue tracker, and discuss.python.org in the future we hope that you’ll extend a warm welcome! We’re eager to get her up and running to reduce the stress that users have been experiencing around PyPI support and further our work to improve and extend PyPI sustainably.

Announcing Our New Infrastructure Engineer

We are excited to announce that Jacob Coffee has joined the Python Software Foundation staff as an Infrastructure Engineer bringing his experience as an Open Source maintainer, dedicated homelab maintainer, and professional systems administrator to the team. Jacob will be the second member of our Infrastructure staff, reporting to Director of Infrastructure, Ee Durbin.

Joining our team, Jacob will share the responsibility of maintaining the PSF systems and services that serve the Python community, CPython development, and our internal operations. This will add crucially needed redundancy to the team as well as capacity to undertake new initiatives with our infrastructure.

Jacob shares, “I’m living the dream by supporting the PSF mission AND working in open source! I’m thrilled to be a part of the PSF team and deepen my contributions to the Python community.”

In just the first few days, Jacob has already shown initiative on multiple projects and issues throughout the infrastructure and we’re excited to see the impact he’ll have on the PSF and broader Python community. We hope that you’ll wish him a warm welcome as you see him across the repos, issue trackers, mailing lists, and discussion forums!

The 2024 PSF Board Election is Open!

It’s time to cast your vote! Voting is open starting today Tuesday, July 2nd, through Tuesday, July 16th, 2024 2:00 pm UTC. Check the Elections page to see how much time you have left to vote.

How to Vote

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

Three seats on the board are open, but you can approve as many of the 19 candidates as you like. We’re delighted by how many of you are willing to contribute to the Python community by serving on the PSF Board! Make sure you take some time to look at all the nominee statements and choose your candidates carefully. ATTN: Choose carefully before you press the big green vote button. Once your vote is cast, it cannot be changed.

Who can vote?

You need to be a Contributing, Managing, Supporting, or Fellow member and have affirmed your voting intention by June 25th, 2024, to vote in this election. If you’d like to learn more or sign up as a PSF Member, check out our membership types. You can check your membership status on your User Information page on psfmember.org (you will need to be logged in). If you have questions about your membership or the election please email psf-elections@python.org

Announcing the PSF Board Candidates for 2024!

What an exciting list! Please take a look at who is running for the PSF Board this year on the PSF Board Election 2024 Nominees page. This year there are 3 seats open on the PSF board. You can see who is currently on the board on the PSF Officers & Directors page. (Débora Azevedo, Kwon-Han Bae, and Tania Allard are at the end of their current terms.)

Board Election Timeline

• Nominations open: Tuesday, June 11th, 2:00 pm UTC
• Nomination cut-off: Tuesday, June 25th, 2:00 pm UTC
• Voter application/affirmation cut-off date: Tuesday, June 25th, 2:00 pm UTC
• Announce candidates: Thursday, June 27th
• Voting start date: Tuesday, July 2nd, 2:00 pm UTC
• Voting end date: Tuesday, July 16th, 2:00 pm UTC

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

Voting

Voting opens on Tuesday, July 2nd at 2:00 pm UTC, through Tuesday, July 16th, 2024 2:00 pm UTC. Check the Elections page to see how much time you have left to vote. 

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

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

FAQ for Proposed Changes to PSF Bylaws

As part of the PSF Board Election, there are three proposed changes to the PSF Bylaws which will be on the upcoming ballot. We have received a significant amount of feedback relating to proposed change #3 (allowing for the removal of Fellows by a majority vote of the Board of Directors). We have been working on a response, which has taken us some time because we want to be as transparent as possible, and there have been many questions raised over the last week or so. Thank you for voicing feedback and your patience with us while we worked on our response.

Please keep in mind that as we are the group who is responsible for the health of the Foundation, we need to be conscious about our statements. There may be direct consequences for our words, and some of the specifics are legally privileged.

The broad categories of questions we’ve included are about the importance of this change, alternatives that were considered and rejected, how the Board is structured against abuse of this change, and a few general questions.

If your specific question isn’t answered here, please join the PSF Board Election Bylaws Office Hour session on Thursday June 27th at 1PM UTC in the #psf-elections channel on the PSF Discord. You can also email your questions to either psf-elections@pyfound.org or membership-wg@pyfound.org or by responding to the For your consideration: Proposed bylaws changes to improve our membership experience thread on the PSF Discuss forum.

We hope that our transparency, the Office Hour session, and our responses in the FAQ below encourage you to vote in favor of all three of the proposed Bylaw changes.

With thanks,

- The PSF Board of Directors

 

Importance of a measure like this

 

Q: Why is this even necessary? What kind of legal advice did you ask for?

A: The Board has a responsibility to act in the interests of the Foundation. Our legal counsel has advised us of a possibility where knowingly allowing a bad actor to continue to operate with our implied endorsement would open us up to certain kinds of liability. Our Bylaws do not currently have a mechanism for revoking the Fellow designation, and this change is intended to close that gap.

The text of all three Bylaws changes were proposed or vetted by our legal counsel, and we are confident that the text as proposed allows us to act according to the intent we described in our original post.

Q: Is this in response to a specific event?

A: The Board needs to balance transparency with our duty to act in the best interest of the Foundation. We can’t discuss any events that would hypothetically lead to removing a Fellow, or even whether there have even been any events that would warrant a removal, because releasing details — or even the existence — of investigations where we failed to remove a fellow would open us up to the possibility of liability.

Q: Does the Board stand by this amendment? Was this a majority or a unanimous decision?

A: The board voted unanimously in favor of this amendment, 10 in favor, 0 against, 0 abstentions. While the Bylaws do not allow proxy votes to be formally counted, both Board members who could not attend the meeting also explicitly registered their support for the amendment with other Board members.

Q: Why can’t we publicly discuss Fellows who have received complaints and decide together as a community?

A: Some people will not make Code of Conduct reports if they are likely to go to a large public discussion or are unlikely to be acted on. The current lifelong nature of the Fellow designation has created a special group of people who are functionally exempt from the effects of the Code of Conduct.

Q: Does the Board retain legal counsel?

A: Even though there is no longer a full-time General Counsel as part of the Board of Directors, the PSF retains legal counsel. Legal advice was sought, provided, and followed as part of this amendment process.

Q: How do changes to the Bylaws work?

A: The PSF’s Bylaws define the legal structure of the Foundation, the Membership, and how the organization is governed. If an aspect of Membership or the Board’s ability to make decisions needs to be changed, the Bylaws need to be changed. This usually happens by discussion amongst the Board, working groups, or even directly from the Membership, resulting in a proposal to amend the Bylaws.

To change the Bylaws, the Board must vote on a proposed amendment, and then the Membership usually has the opportunity to vote to approve those changes. As an organization that represents a diverse community, we strongly value the consent and community buy-in that comes from a vote.

There are other ways to change the bylaws, including not seeking Member approval, or by Membership seeking Bylaws changes without Board approval, but these have never been used.

Alternatives considered and rejected

 

Q: Why does this only require a majority vote, not a supermajority?

A: This amendment as written already requires a higher standard than most business the Board handles. It requires a majority of the full Board of Directors, not merely a majority of the quorum (as is otherwise required in Section 5.8).

With the current size of the Board, a majority is 7 Directors, and a supermajority (two thirds) is 8. The Board would be open to amending the requirements to a supermajority in the future, but we wish to highlight how small the difference would be in practice.

Q: Why does this not require a unanimous vote?

A: A unanimous vote requirement would create scope for abuse. A unanimous vote requirement would allow for a single dissenting Director to prevent the removal of a problematic Fellow, opening the Foundation to liability.

In certain cases, that liability could extend to individual Directors, even those who voted to remove the Fellow, simply because the action failed to pass due to one dissenting vote (subject to the provisions of Article XII “Limits on Liability of Directors”).

This personal liability would be a significant barrier to many community members' willingness to serve on the Board.

Protections against misuse

 

Q: Why does the Board need to act responsibly?

A: The Board needs to act in the service of the Foundation’s mission, and has a responsibility to the community to keep vital infrastructure like PyPI running, providing fiscal sponsorship to community groups like PyLadies chapters, or giving grants to international communities.

Acting against the interests of the membership would cause the community to lose trust in us, and threaten our ability to keep Python’s infrastructure running.

Q: What protections are available to prevent the Board from misusing this provision?

A: This proposed Bylaws amendment requires a Member to fail a “condition of membership” to be removed. Such a condition would need to have been previously enacted by the Board and would apply to any Member in that class of Membership. This prevents the Board from removing a Member arbitrarily.

The Membership regularly holds the Board accountable through annual elections. Should there be an immediate need to act, the Membership can call a special meeting of the Board or the Membership and hold the Board to account. The proposed change allows a removed Member 15 business days before their removal is final, during which time they can use the tools available to hold the Board to account.

Q: What if a future board becomes controlled by a large group of untrustworthy and like-minded people?

A: The Board is elected in cohorts, such that usually only 3-4 seats are open each year. Any “hostile takeover” would need to be conducted over the course of a few years and could not be engineered by any company or other formal entity because we already have rules preventing Board capture in our Bylaws (section 5.15).

“No more than one quarter (1/4) of the members of the Board of Directors may share a common affiliation.”  

Other questions

 

Q: Why does this offer the possibility of covering non-Code of Conduct policies?

A: The Amendment gives the Board the right to add other qualifications to membership, and the Bylaws do not prevent the Board from amending the Code of Conduct (and we have done so multiple times before). If we were to change the Bylaws such that the only policy that allowed us to remove members was the Code of Conduct, this would have the perverse effect of incentivizing the Board to amend the Code of Conduct to cover other cases where removing a Member may be a necessity. This would make the Code of Conduct too long, complicated, and unfocused to be effective in the cases where it is already used.

Q: Why did the Board single out Fellows in the announcement?

A: It is true that the amended text covers all classes of Membership, however, in practice the only truly new ability granted to the board is being able to remove Fellows.

The text of the Bylaws already grants mechanisms that could allow the Board to make Members in other classes ineligible for Membership, including the ability to set “alternate eligibility criteria” (section 4.6-4.7) beyond those in the Bylaws or an “applicable membership fee” (section 4.5). The only class of membership for which there is no way to restrict eligibility on existing Members are the Fellows, who are granted life membership, except if they are removed by a vote of the Membership. This amendment makes it possible to remove Members, no matter which class, using the same tools.

Q: Who comprises the Code of Conduct Work Group? Is it diverse? Are they accepting new members?

A: The current membership and the past members of the Conduct Work Group are listed in the charter which can be found on the Code of Conduct Work Group Charter page. The group consists of diverse representatives from around the world. The charter lists the process for applying to join the Work Group.

The Python Language Summit 2024: PyREPL -- New default REPL written in Python

Lysandros showing the mistake we've all made, no longer a problem in the new REPL
(Photo credit: Hugo van Kemenade)

One of the headline features of Python 3.13 is the new interactive interpreter, sometimes known as a "REPL" (Read-Evaluate-Print-Loop) which was contributed by Pablo Galindo Salgado, Łukasz Langa, and Lysandros Nikolaou and based on the PyPy project's own interactive interpreter, PyREPL. Pablo, Łukasz, and Lysandros all were at the Language Summit 2024 to present about this new feature coming to Python.

Why does Python need a new interpreter?

Python already has an interactive interpreter, so why do we need a new one? Lysandros explained that the existing interpreter is "deeply tangled" to Python's tokenizer which means adding new features or making changes is extremely difficult.

To lend further color to this point, Lysandros dug into how the tokenizer had changed since Python was first developed. Lysandros noted that "for the first 12 years [of Python], Guido was the only one who touched the tokenizer" and only later after the parser was replaced did anyone else meaningfully contribute to the tokenizer.

Terse example code for Python's tokenizer

Meanwhile, there are other REPLs for Python that "have many new features that [Python's] interpreter doesn't have that users have grown to expect", Lysandros explained. Some basic features that were listed as examples included lack of color support meaning no syntax highlighting, the ergonomics issues around exit versus exit(), no support for multi-line editing and buffer history, and poor ergonomics around pasting code into the interpreter.

Why PyREPL?

"We've settled on starting our solution around PyREPL", Pablo explained, "our reasoning being that maintaining terminal applications is hard. Starting from scratch would have a much higher risk for users". Pablo also noted that "most people who would interact with the REPL wouldn't test in betas", because Python pre-releases are generally used for running automated tests in continuous integration and not interactively tested manually.

Pablo explained that there are many different terminals and platforms which are all sources of behaviors and bugs that are hard to get right the first time. "[PyREPL] provided us with a solid base that we know works and we can start modifying".

Tasteful modern art or bug in the REPL?

Another major contributing factor was that PyREPL is written in Python. Pablo emphasized that "now people that want to start contributing to the REPL can actually contribute because it's written in Python".

Finally, Pablo pointed out that because the implementation is now partially shared between CPython and PyPy that both implementations can benefit from bug fixes to the shared parts of the codebase. Support for Chinese characters in the REPL was fixed in CPython and is being contributed back to PyPy.

Łukasz noted that adopting PyREPL wasn't a straightforward copy-paste job, there were multiple ideas in PyPy's PyREPL that don't make sense for CPython. Notably, PyPy is written to also support Python 2, so the code was simplified to only handle Python 3 code. PyREPL for PyPy also came with support for PyGame which wasn't necessary for CPython.

Type hints and strict type checking using mypy were also added to PyREPL, making the PyREPL module the first in the Python standard library to be type-checked on pull requests. Adding type hints to the code immediately found bugs which were fixed and reported back to PyPy.

What are the new features in 3.13?

Pablo gave a demonstration of the new features of PyREPL, including:

• Colored prompts
• F1 for help, F3 for bracketed paste
• Multi-line editing and history
• Better support for pasting blocks of code
   

Below are some recreated highlights from the demo. Pasting code samples into the old REPL that contain multiple newlines would often result in SyntaxErrors due to multiple newlines in a row resulting in that statement being evaluated. Multi-line editing also helps modifying code all in one place rather than having to piece a snippet together line-by-line, modifying what you want as you go:

Demo of multi-line paste in Python 3.13

 

And the "exit versus exit()" paper-cut has been bothering Python users for long enough. This error was especially taunting because the REPL clearly knows what your intent is with it's helpful message to "Use exit() to exit":

"exit" without parenthesis just works, finally!

Windows and terminals

Support is already available for Unix consoles (Linux and macOS) in Python 3.13.0-beta1 and the standout feature request so far for PyREPL has been Windows support. Windows was left out because "historically the console on Windows was way different than Unix consoles". Łukasz continued, saying that "they don't intend to support right now" offering a "yes, but..." for users asking for Windows support.

Windows has two consoles today, cmd.exe of yore and the new "Windows Terminal" which supports many of the same features as Unix consoles including VT100 escape codes. The team's plan is to support the new Windows Terminal, and "to use our sprints here in Pittsburgh to finish". Windows support will also require removing CPython dependencies on the curses and readline libraries.

What's next for PyREPL?

The team already has plans cooking up for what to add to the REPL in Python 3.14. Łukasz commented that "syntax highlighting is an obvious idea to tackle". Łukasz also referenced an idea from Tania Allard for accessibility improvements similar to those in IPython.

Łukasz reiterated that the goal isn't to make an "uber REPL" or "replace IPython", but instead to make a REPL that core developers can use while testing development branches (where dependencies aren't working yet).

Łukasz continued that core developers aren't the only ones that these improvements benefit: "many teachers are using straight-up Python, IDLE, or the terminal because the computers they're using don't allow them to install anything else."

Given the applause from the room during the demos, it's safe to say that this work has been received well. There were only concerns about platform support and rollout for the new REPL.

Gregory Smith informed the team that functionality that requires a "Function" key (ie F1, F2, etc) must also be supported without Function keys due to some computers lacking them, like Chromebooks.

Carol Willing was concerned about releasing PyREPL without support for Windows Terminal, especially from a teaching perspective, describing that potential outcome as "painful". Carol wanted clear documentation on how to get the new REPL on Windows. "Positioning [the new REPL] for teaching without clear Windows instructions is a recipe for disaster".

Pablo assured that the team wants to add support for Windows Terminal in time for the first 3.13 release candidate. Pablo could not make guarantees due to a lack of Windows expertise among the three, saying "the reason I'm not saying 100% is because none of us are Windows experts. We understand what needs to be done... but we need some help."

Łukasz named Steve Dower, the Windows release expert for Python, who is "very motivated to help us get Windows Terminal support during sprints". Łukasz reiterated they're "not 100%, but we are very motivated to get it done".

Gregory Smith shared Carol's concern and framed the problem as one of communication strategy, proposing to "not promise too much until it works completely on Windows". By Python 3.14 the flashy features like syntax highlighting would have landed and the team would have a better understanding of what's needed for Windows. The team can revise the 3.13 "What's New in Python" depending on what gets implemented in the 3.13 timeline.

Ned Deily sought to clarify what the default experience would be for users of 3.13. Pablo said that "on Windows right now you will get the [same REPL] that you got before" and "on Linux and macOS, if your terminal supports the features which most of them do, you get the enhanced experience". "What we want in the sprints is to make Windows support the new one, if we get feature parity, then [Windows] will also get the new [REPL]".

Carol also asked to document how to opt-out of the new REPL in the case that support wasn't added in time for 3.13 to avoid differences between educational material and what students were seeing in their terminal. Kushal Das confirmed that differences across platforms is a source of problems for students, saying that "if all [students] have the same experience it's much better than just improving only macOS and Linux" to avoid students feeling bad just due to their operating system.

Pablo said that the opt-out mechanism was already in place with an environment variable and will discuss other opt-out mechanisms if needed for educators.

Emily Morehouse, speaking as a Steering Council member added that the Steering Council has requested an informational PEP on the new REPL. "Hearing concerns about how [the new REPL] might be rolled out... it sounds like we might need something that's more compatible and an easier rollout", leaving the final discussions to the 3.13 release manager, Thomas Wouters. Carol replied that she believes "we could do it in documentation".

The Python Language Summit 2024

The Python Language Summit occurs every year just before PyCon US begins, this year occurring on May 15th, 2024 in Pittsburgh, Pennsylvania. The summit is attended by core developers, triagers, and Python implementation maintainers for a full day of talks and discussions on the future direction of Python.

This years summit included talks on the C API, free-threading, the security model of Python post-xz, and Python on mobile platforms.

This year's summit was attended by around 45 people and was covered by Seth Larson.

Attendees of the Python Language Summit 2024
(Photo credit: Kushal Das)

• Should Python adopt Calendar Versioning?: talk by Hugo van Kemenade
  
• Python's security model after the xz-utils backdoor: talk by Pablo Galindo Salgado
  
• Native Interface and Limited C API: talks by Petr Viktorin and Victor Stinner
  
• Free-threading ecosystems: talk by Daniele Parmeggiani
  
• Python on Mobile: talk by Malcolm Smith
• PyREPL -- New default REPL written in Python: talk by Pablo Galindo Salgado, Łukasz Langa, and Lysandros Nikolaou
• Should we make pdb better?: talk by Tian Gao
  
• Limiting yield in async generators: talk by Zac Hatfield-Dodds
• Annotations as Transforms: talk by Jason R. Coombs
  
• Lightning Talks, featuring talks by Petr Viktorin, David Hewitt, Emily Morehouse, Łukasz Langa, Pablo Galindo Salgado, and Yury Selivanov

 

 

 

 

 

The Python Language Summit 2024: Lightning Talks

The Python Language Summit 2024 closed off with six lightning talks which were all submitted during the Language Summit. The talks were delivered by Petr Viktorin, David Hewitt, Emily Morehouse, Łukasz Langa, Pablo Galindo Salgado, and Yury Selivanov.

Petr Viktorin: Unsupported build warning

Do you know what happens when you build Python on an unsupported platform?

"... It works!" -- Thomas Wouters

Petr gave a short presentation on a warning that many folks using Python (and even developing Python!) may have never seen before: the unsupported build warning. This warning appears when building on a platform that's not officially supported by CPython, for example "riscv64-unknown-linux-gnu".

"The platform is not supported, use at your own risk"
(Photo credit: Hugo van Kemenade)

 

Just because a platform isn't officially supported by CPython doesn't mean it won't work on that platform, and indeed it's likely that CPython may work fine on the platform or a subset of features may be subtly or not-so-subtly broken or unavailable.

Petr wanted to get a temperature check from the group on whether this warning could be further improved or changed, such as by hiding the warning after the user had executed the test suite or showing the number of tests that had failed.

The room seemed mostly uninterested in exploring this topic further and was in favor of keeping the warning as-is.

The Python Language Summit 2024: Annotations as Transformers

The final talk of the main schedule of the Python Language Summit was delivered by Jason R. Coombs on using annotations for transforms. The presentation was accompanied by a GitHub repository and Jupyter notebook illustrating the problem and proposed solution.

Jason is interested in a method for users to "transform their parameters in a reusable way". The motivation was to avoid imperative methods of transforming parameters to "increase reusability, composition, and separation of concerns". Jason imagined transformers which could be "packaged up in a library or used across multiple functions" and would "be applied at the scope of individual parameters".

Python already has a language feature that's similar to this concept with decorators, which allow wrapping a function or class with another function in a syntactically concise way.

Jason noted that "return values can be handled by decorators fairly easily, so [the proposal] is more concerned with input parameters". For a decorator to affect parameters, the decorator "would have to inspect the parameters" and "entangle itself with the function signature".

Diagram from Jason's presentation showing transforms being applied to individual parameters of a function.

Jason's proposal would use type annotations due to type annotations already specifying the desired type, the proposal being to add behavior "this is the type I want to make this" and perform transforms. Below is some example code of the proposal:

def transformer(val: float | None) -> float:
    return val if val is not None else 0

def make_str(val: float) -> str:
    return str(val)

def my_fn(
    p1: transformer,
    p2: transformer
) -> make_str:

    return (p1 ** 2) + p2

Jason went on to show that Pydantic was offering something similar to his proposal by having functions called on parameters and return values using the pydantic.BeforeValidator class in conjunction with typing.Annotated, though this use-case "wasn't being advertised by Pydantic":

from typing import Annotated
import pydantic

def transformer(val: float | None) -> float:
    return val if val is not None else 0

@pydantic.validate_call(validate_return=True)
def my_fn(
    p1: Annotated[float, pydantic.BeforeValidator(transformer)],
    p2: Annotated[float, pydantic.BeforeValidator(transformer)]
) -> Annotated[str, pydantic.BeforeValidator(str)]:

    return (p1 ** 2) + p2

Jason didn't like this approach though due to the verbosity, requiring to use a decorator and provide annotations, and needing an extra dependency.

Eric V. Smith asked if Jason had seen PEP 712, which Eric is the sponsor of, that describes a "converter" mechanism for dataclass fields. This mechanism was similar in that "the type you annotated something with became different to the type you passed". Eric remarked it was "pretty common thing that people want to pass in different types when they're constructing something than the internal types of the class".

Jason replied that he had seen the PEP but "hadn't incorporated it into a larger strategy yet". Steering council member Barry Warsaw noted that he "didn't know what the solution is, but it is interesting... that the problems are adjacent".

There was skepticism from the room, including from typing council member Guido van Rossum, on using type annotations as the mechanism for transformers. Type annotations today don't affect the runtime behavior of the code and this proposal would be a departure from that, Guido noting "process-wise, that's going to be a difficult hurdle".

If type annotations weren't the way forwards, Jason had also considered proposing new syntax or a new language feature and wanted feedback on whether "there's viability" in that approach and if so, "[he] could explore those options".

There were questions about why decorators weren't sufficient, citing PEP 318 motivation section containing examples similar to the ones Jason had presented. Transformers could be assigned to parameters by name, passing in the transformer as a key-value parameters into the decorator like so:

def transformer(val: float | None) -> float:
    return val if val is not None else 0

@apply(p1=transformer, p2=transformer)
def my_fn(
    p1: float,
    p2: float
) -> float:

    return (p1 ** 2) + p2

Jason found this pattern "discouraging" and "less elegant" because the variable name needs to mentioned in multiple places and that he was "hoping for something that was more integrated into the language, to not feel like a second-class feature".

Łukasz Langa commented on the case for removing the "None" type from a union, could already be done with a type guard and drew attention to work being done to allow more complicated type guards. Łukasz was "sympathetic to conciseness, but type checkers already handle this".

Steering Council member Gregory Smith was hesitant to make any change in this area. He agreed that "as a language, we're missing something", but "wasn't sure if we've got a way forward that doesn't make the language more complicated".

The Python Language Summit 2024: Limiting Yield in Async Generators

Zac Hatfield-Dodds came to the Language Summit to present on a fundamental incompatability between the popular async programming paradigm "structured concurrency" and asynchronous generators, specifically when it came to exception handling when the two were mixed together.

Structured Concurrency

Structured concurrency is becoming more popular for Python async programming like with Trio "nurseries" and in the Python standard library with the addition of asyncio.TaskGroup in Python 3.11.

When using structured concurrency, active tasks can be thought of as a tree-like structure where sub-tasks of a parent task have to exit before the parent task itself can proceed past a pre-defined scope. This exit can come through all the tasks completing successfully or from an exception being raised either internally or externally (for example, in the case of a timeout on time-bounded work).

The mechanism which allows a parent task and its sub-tasks to cooperate in this way is called a "cancel scope" which Trio makes a top-level concept but is implicitly used in asyncio.TaskGroup and asyncio.timeout.

Async programs that are structured with this paradigm can rely on exceptions behaving in a much more recognizable way. There's no more danger of a spawned sub-task silently swallowing an exception because all sub-tasks are guaranteed to be checked for their status before the parent task can exit.

The problem with yields

The fundamental issue is that yields suspend the current call frame, in effect "returning" a value, and then the generator needs to be "called" again for execution to be resumed. This suspension doesn't play well with structured concurrency because execution can't be suspended in the same call frame as a cancel scope, otherwise that scope can't process exceptions from its child tasks.

Zac leading a "fun game of 'why is this code broken?'"
(Photo credit: Hugo van Kemenade)

Zac presented some innocuous looking code samples that suffered from the described issue:

async def iter_with_timeout(ait, max_time):
    try:
        while True:
            with asyncio.timeout(max_time):
                yield await anext(ait)
    except StopAsyncIteration:
        return

async def fn():
    async for elem in iter_with_timeout(ait, max_time=1.0):
        await do_something_with(elem)

In this example, asyncio.timeout() could expire while the yield had suspended the generator and before the generator was resumed. This scenario would result in the cancellation exception being raised in the outer task outside of the asyncio.timeout() cancel scope. If things had gone to plan and the generator wasn't suspended the cancellation would be caught by asyncio.timeout() instead and execution would proceed.

Zac presented the following fix to the iter_with_timeout() function:

async def iter_with_timeout(ait, max_time):
    try:
        while True:
            with asyncio.timeout(max_time):
                tmp = await anext(ait) 
            yield tmp  # Move yield outside the cancel scope!
 except StopAsyncIteration:
        return

By moving the yield outside the cancellation scope it means that the suspension of the frame isn't happening when execution is inside a cancellation scope. This means that propagation of cancellation errors can't be subverted by a suspended call frame for this program.

If you're still having trouble understanding the problem: you are not alone. There was a refrain of "still with me?" coming from Zac throughout this talk. I recommend looking at the problem statement and motivating examples in the PEP for more information.

Where to go from here

Zac and Nathaniel Smith have coauthored PEP 789 with their proposed solution of disallowing yield statements within context managers that behave like cancel scopes. Attempting to yield within these scopes would instead raise a RuntimeError.

The mechanism would be using a new function "sys.prevents_yields()" which would be used by authors of async frameworks to annotate context managers which can't be suspended safely. Users of async frameworks wouldn't need to change their code unless it contained the unwanted behavior.

The language would need to support this feature by adding metadata to call frames to track whether the current frame should allow yields to occur.

Mark Shannon was concerned that the solution was "lots of machinery to handle the exception being raised in the wrong place" and sought clarification that there would be overhead added to every call and return. Zac confirmed this would be the case, but that it could be done with "one integer [member on call frames] that you increment and decrement, but it would do some operation on every frame call and return".

Irit Katriel asked why a "runtime error" was being used "instead of something static". Zac explained that users might define their own context managers which have a "cancel scope property" and the runtime "wouldn't know statically whether a given context manager should raise an error or not".

Łukasz Langa asked whether adding a type annotation to context managers would be sufficient to avoid adding runtime overhead. Zac responded that "there are still many users that don't use static type checking", and that "there's no intention to make it required by default". Łukasz was concerned that the proposal "would be contentious for runtime performance" due to the impact being "non-trivial".

Pablo Galindo Salgado wanted to explore other big ideas to avoid the performance penalty like adding new syntax or language feature, such as "with noyield" to provide a static method of avoiding the issue. Zac agreed that changing the context manager protocol could also be a solution.

Guido van Rossum lamented that this was "yet another demonstration that async generators were a bridge too far. Could we have a simpler PEP that proposes to deprecate and eventually remove from the language asynchronous generators, just because they're a pain and tend to spawn more complexity".

Zac had no objections to a PEP deprecating async generators¹. Zac continued, "while static analysis is helpful in some cases, there are inevitably cases that it misses which kept biting us... until we banned all async generators in our codebase".

¹ Editors note: after the summit an update to PEP 789 would describe how the problem doesn't exist solely in async generators and thus removal of the feature wouldn't solve the problem, either.

The Python Language Summit 2024: Should we make pdb better?

Tian Gao came to the Language Summit 2024 to talk about improving pdb, short for "Python debugger", a module and command line tool for debugging Python.

Tian Gao presenting on how to improve pdb

There are not many command-line debugger alternatives to pdb for Python. Tian mentioned a few, including PuDB, pdb++, and ipdb, but those alternatives are all themselves based on either pdb or another standard library module 'bdb'.

pdb is the only "standalone" command-line-based Python debugger

Tian presented a laundry list of desirable new features that could be added to pdb, including:

• Showing more lines of code around the current breakpoint.
• Colors in the terminal, syntax highlighting.
• Customization, with defaults being safe.
  
• Handling of more scenarios (threads, asyncio, bytecode, remote debugging)
  

Performance and backwards compatibility

The biggest issue according to Tian, which he noted had been discussed in the past, was the performance of pdb. "pdb is slow because sys.trace is slow, which is something we cannot change", and the only way forward on making pdb faster is to switch to sys.monitoring to avoid triggering unnecessary events.

Switching to sys.monitoring would give a big boost to performance. According to Tian, "setting a breakpoint in your code in the worst case you get a 100x slowdown compared to almost zero overhead with sys.monitoring". Unfortunately, switching isn't so easy, Tian noted there are serious backwards compatibility concerns for the standard library module bdb if pdb were to start using sys.monitoring.

"If we're not ready to [switch to sys.monitoring] yet, would we ever do this in the future?", Tian asked the group, noting that an alternative is to create a third-party library and encourage folks to use that library instead.

Thomas Wouters started off saying that "bdb is a standard library module and it cannot break user code" and cautioned that core developers don't know who is depending on modules. bdb's interface can't have backwards incompatible changes without long deprecation periods. In Thomas' mind, "the answer is obvious, leave pdb as it is and build something else".

Thomas also noted "in the long-term, a debugger in the standard library is important" but that development doesn't need to happen in the standard library. Thomas listed the benefits for developing a new debugger outside the standard library like being able to publish outside the Python release schedule and to use the debugger with older Python versions. Once a debugger reaches a certain level of stability it can be added to the standard library and potentially replace pdb.

Tian agreed with Thomas' proposal in theory, but was concerned that a third-party debugger on PyPI wouldn't see the same levels of adoption compared to being in the standard library and thus would struggle to meet a threshold of "stability" without a critical mass of users. Or worse yet, maintainers wouldn't be motivated to continue due to a lack of use, resulting in a "dead project". (Some foreshadowing, Steering Council member Emily Morehouse gave a lightning talk on this topic later on in the Language Summit)

Łukasz Langa noted that Python now has support for "breakpoint()" and that "what breakpoint() actually does, we can change. We can run another debugger if we decide to", referencing if a better debugger was added in the future to CPython that it could be made into a new default for breakpoints.

Russell Keith-Magee from BeeWare, was interested in what Tian had said about remote debugging, noting that "remote debugging is the only way you can debug [on mobile platforms]". Russell would be interested in pdb or a new debugger supporting this use-case. Tian noted that unfortunately remote debugging would be one of the more difficult features to implement.

Pablo Galindo Salgado, commenting on existing Python "attach-to-process" debuggers, said that the hacks in use today are "extremely unsafe". Pablo said that "we'd need something inside CPython [to be safe], but then you have another problem, you have to implement that feature on [all platforms]". Pablo also mentioned that attach-to-process debugging is usually a bad model because it can't be enabled by default for security reasons but "you won't know when you'll need to debug".

Anthony Shaw asked about the scope of the project and was interested in whether there could be a framework for debugging in CPython that pdb and others could build on. Anthony pointed out that many other debuggers "needed to do a bunch of hooks and tricks" to do debugging because it's "not provided out of the box by CPython".

Tian responded that "bdb is supposed to do that, but it was written 30 years ago so is too old to support new things that a debugger wants". Others mentioned that sys.monitoring (new in Python 3.12) was meant to be a framework for debuggers to build on.

Gregory Smith, Steering Council member, said he "wants all of these things" and agreed with Thomas to "develop this as much as you can... outside of the standard library", telling Tian that "you're going to end up in a better state that way". Greg's primary concern was whether CPython needed to do anything to enable Tian's proposal. He continued, "it sounds like we (CPython) have most of what we need, but if we don't let's get that planned so we can enable a successful separate project before we ship it with Python in the future".