python-committers September 2018

python-committers@python.org

47 participants
20 discussions

GitHub: remove the "needs backport to 3.5" label?

by Victor Stinner

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

1 year, 11 months

Licences for PyCharm and other JetBrains products

by Vinay Sajip

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 years, 7 months

1 week to Oct 1

by Mariatta Wijaya

It is now 7 days until October 1, the deadline for coming up with Python Governance PEPs. Some still relevant links: - https://www.python.org/dev/peps/pep-8000/ Python Language Governance Proposal Overview - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process - https://www.python.org/dev/peps/pep-8002 Open source governance survey These are current ideas and proposals, some are placeholders still. - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm claiming this PEP) - https://www.python.org/dev/peps/pep-8012 The Community Governance Model - https://www.python.org/dev/peps/pep-8013/ The External Council Governance Model - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model I have some questions: 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? 2. How do we discuss these PEPs? 3. At the sprint, there's a small workgroup formed for coming up with the procedure to vote. How is that coming? Could someone please write up a brief summary? (perhaps as a separate email thread) I think it would be great to have this written up soon, before Oct 1. Thanks. Mariatta ᐧ

2 years, 9 months

python-committers is dead, long live discuss.python.org

by Łukasz Langa

Hello committers, since this got pretty long, here's the tl;dr: - we're at the point where it is hard to make mailing lists work for us; - we're switching to Discourse; it's better in many ways; - go to https://discuss.python.org/ <https://discuss.python.org/> and create your account there; - please do not post to python-committers for the remainder of the year to give Discourse a real shot. And now the long version. What's the issue? During the core sprint in Redmond we discussed how we discuss. The overwhelming feel is that we have reached the limits of what is possible with mailing lists. We identified e-mail as a contributor to some of the problems we're dealing with now. To fix more and whine less, I talked with everybody in Redmond about a possible replacement for the trusty mailing list. We identified one: Discourse. What is it? Discourse is forum software started in 2013 by Jeff Atwood, Robin Ward, and Sam Saffron. It's used by many large scale open source projects and companies, including Github Atom, Twitter Developers, Rust, Kotlin, Elixir, Docker, Codeacademy, Patreon, EVE Online, and Imgur. It's open source (Ruby, GPL2), it supports plugins and has an API. Why is it better than e-mail? It's both a Web app and a terrific mobile application. It supports regular flat conversational threads and collapsible replies. There is community moderation where users can flag inappropriate messages to notify moderators, moderators and authors can lock topics, move discussions between categories, archive things that are no longer applicable, and so on. You can edit posts, quote posts, link between posts, add rich media, code snippets with syntax highlighting, there's Markdown support. You can still use it via e-mail similarly to how GitHub notifications work. See: https://meta.discourse.org/t/set-up-reply-via-email-support/14003 <https://meta.discourse.org/t/set-up-reply-via-email-support/14003> There is a user trust system where proven community members get more power in time, for example to fix typos and move topics to a better category. There's much more: dynamic notifications, topic summaries, emojis, spam blocking, single sing-on, two-factor authentication, social login support, and so on. Read: https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298 <https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298>. What about Zulip? Zulip is chat software which some of us find useful but its UI is proving to be challenging for many of us, the mobile application leaves a lot to be desired, and it did not end up moving discussions out of the mailing lists. I see Zulip as replacement for IRC whereas Discourse is replacement for mailing lists (or both; we'll see!). Where do I sign up? Create an account at https://discuss.python.org/ <https://discuss.python.org/>. You'll recognize the set up as essentially mirroring the main mailing lists: - Committers - Users - Ideas There's also Discourse-specific sections: - Discourse Feedback (post here if things don't work like you'd like) - Discourse Staff (hidden category for moderators and admins of the instance, boring discussion) - Inquisition (hidden category for users with trust level 3+) As you can see, I combined python-committers and python-dev into just "Committers". If we find in the future that this is too limiting, we can always open up another category. For now though I'd like to avoid the fate of python-dev where there's 20k+ subscribers and we don't know who is who. CALL TO ACTION We'd like to heavily test this new forum. As such, I would like to ask you to NOT USE python-committers for the remainder of the year and direct all conversation to Discourse. The goal to replace the mailing lists with Discourse met unanimous support at the core sprint. As long as we don't identify any deal breakers in October, I will send an e-mail like this to python-dev on November 1st, and to python-list and python-ideas on December 1st. If everything goes smoothly, those four mailing lists will be archived by end of this year. Other mailing lists are welcome to port over to Discourse too. Acknowledgements Pablo and Ernest worked on setting up this instance for us (thank you both! 🖤). The question whether Discourse or the Python Software Foundation are going to pay for this infrastructure is still open but, as Elon Musk likes to say, funding is secured. Yury and I are helping in configuring the instance. Future work We'll be enabling GitHub and social logins soon, ideally with adding identified committers to the committers group by default. We are looking into this right now. In the mean time, please request membership, an existing member will add you. We'd like to migrate old discussion off of the mailing lists to our Discourse instance so that search is immediately useful. We'll look into that after the governance crisis is resolved. - Ł

2 years, 9 months

[PEP 8013] The External Council Governance Model

by Steve Dower

Here is the text of PEP 8013 for discussion and improvement (in isolation from the other proposals, of course -- we're not ready for the shoot-out yet.) I'm keen to see the model be considered, but I don't feel the need to tightly control the specific content in the PEP, so feel free to send your own PRs if you have definitive improvements. For the next few days I'm also going to have varying amounts of ability to read and respond to email. I'll try and catch up by the weekend or early next week. Rendered version at: https://www.python.org/dev/peps/pep-8013/ --- PEP: 8013 Title: The External Council Governance Model Author: Steve Dower <steve.dower(a)python.org> Status: Draft Type: Informational Content-Type: text/x-rst Created: 2018-09-14 Abstract ======== This PEP proposes a new model of Python governance based on a Group of Unbiased Independent Directors of Order (GUIDO) tasked with making final decisions for the language. It differs from PEP 8010 by specifically not proposing a central singular leader, and from PEP 8011 by disallowing core committers from being council members. It describes the size and role of the council, how the initial group of council members will be chosen, any term limits of the council members, and how successors will be elected. It also spends significant time discussing the intended behaviour of this model. By design, many processes are not specified here but are left to the people involved. In order to select people who will make the best decisions, it is important for those involved to understand the expectations of GUIDO but it is equally important to allow GUIDO the freedom to adjust process requirements for varying circumstances. This only works when process is unspecified, but all participants have similar expectations. This PEP does *not* name the members of GUIDO. Should this model be adopted, it will be codified in PEP 13 along with the names of all officeholders described in this PEP. Open Discussion Points ====================== Some suggestions in this document are currently weak suggestions, and are open to change during the discussion period. These include: * We can change the name of the group. "Council of Auditors" is the suggested alternative, though "Python Inquisition" is very tempting if we believe we can be clear about the source of the name [1]_ * We can change voting procedures, timelines, and tie-breakage rules The Importance of the Grey Area =============================== In any actual decision-making process, there is going to be grey area. This includes unexpected scenarios, and cases where there is no "correct" answer. Many process plans attempt to minimise grey area by defining processes clearly enough that no flexibility is required. This proposal deliberately goes the other way. The aim is to provide a robust framework for choosing the best people to handle unexpected situations, without defining how those people should handle those situations. Examples are provided of "good" responses to some situations as an illustration. The hope is that the "best" people are the best because they would live up to those examples. The process that is proposed has been designed to minimise the damage that may be caused when those people turn out not to be the best. Grey area is guaranteed to exist. This proposal deliberately embraces and works within that, rather than attempting to prevent it. Model Overview ============== Key people and their functions ------------------------------ The Group of Unbiased Independent Directors of Order (GUIDO) is a council of varying size, typically two to four people, who are elected for the duration of a Python release. One member of GUIDO is considered the President, who has some minor points of authority over the other members. GUIDO has responsibility for reviewing controversial decisions in the form of PEPs written by members of the core development team. GUIDO may choose to accept a PEP exactly as presented, or may request clarification or changes. These changes may be of any form and for any reason. This flexibility is intentional, and allows the process to change over time as different members are elected to GUIDO. See the later sections of this document for examples of the kinds of requests that are expected. GUIDO only pronounces on PEPs submitted to python-committers. There is no expectation that GUIDO follows or participates on any other mailing lists. (Note that this implies that only core developers may submit PEPs. Non-core developers may write and discuss proposals on other mailing lists, but without a core developer willing to support the proposal by requesting pronouncement, it cannot proceed to acceptance. This is essentially the same as the current system, but is made explicit here to ensure that members of GUIDO are not expected to deal with proposals that are not supported by at least one core developer.) GUIDO may not delegate authority to individuals who have not been elected by the core developer team. (One relevant case here is that this changes the implementation of the existing BDFL-Delegate system, though without necessarily changing the spirit of that system. See the later sections for more discussion on this point.) The Release Manager (RM) is also permitted the same ability to request changes on any PEPs that specify the release they are responsible for. After feature freeze, the RM retains this responsibility for their release, while GUIDO rotates and begins to focus on the subsequent release. This is no different from the current process. The process for selection of a RM is not changed in this proposal. Core developers are responsible for electing members of GUIDO, and have the ability to call a "vote of no confidence" against a member of GUIDO. The details of these votes are discussed in a later section. Where discussions between core developers and members of GUIDO appear to be ongoing but unfruitful, the President may step in to overrule either party. Where the discussion involves the President, it should be handled using a vote of no confidence. Members of GUIDO may choose to resign at any point. If at least two members of GUIDO remain, they may request a new election to refill the group. If only one member remains, the election is triggered automatically. (The scenario when the President resigns is described in a later section.) The intended balance of power is that the core developers will elect members of GUIDO who reflect the direction and have the trust of the development team, and also have the ability to remove members who do not honour commitments made prior to election. Regular decision process ------------------------ Regular decisions continue to be made as at present. For the sake of clarity, controversial decisions require a PEP, and any decisions requiring a PEP are considered as controversial. GUIDO may be asked to advise on whether a decision would be better made using the controversial decision process, or individual members of GUIDO may volunteer such a suggestion, but the core development team is not bound by this advice. Controversial decision process ------------------------------ Controversial decisions are always written up as PEPs, following the existing process. The approver (formerly "BDFL-Delegate") is always GUIDO, and can no longer be delegated. Note that this does not prevent GUIDO from deciding to nominate a core developer to assess the proposal and provide GUIDO with a recommendation, which is essentially the same as the current delegation process. GUIDO will pronounce on PEPs submitted to python-committers with a request for pronouncement. Any member of GUIDO, or the current RM, may request changes to a PEP for any reason, provided they include some indication of what additional work is required to meet their expectations. See later sections for examples of expected reasons. When all members of GUIDO and the RM indicate that they have no concerns with a PEP, it is formally accepted. When one or more members of GUIDO fail to respond in a reasonable time, the President of GUIDO may choose to interpret that as implied approval. Failure of the President to respond should be handled using a vote of no confidence. Election terms -------------- Members of GUIDO are elected for the duration of a release. The members are elected prior to feature freeze for the previous release, and hold their position until feature freeze for their release. Members may seek re-election as many times as they like. There are no term limits. It is up to the core developers to prevent re-election of GUIDO members where there is consensus that the individual should not serve again. Election voting process ------------------------ The election process for each member of GUIDO proceeds as follows: * a nomination email is sent to python-committers * a seconding email is sent * the nominee is temporarily added to python-committers for the purpose of introducing themselves and presenting their position * voting opens two weeks prior to the scheduled feature freeze of the previous release * votes are contributed by modifying a document in a private github repository * each core developer may add +1 votes for as many candidates as they like * after seven days, voting closes * the nominee with the most votes is elected as President of GUIDO * the next three nominees with the most votes and also at least 50% the number of votes received by the President are elected as the other members of GUIDO * where ties need to be resolved, the RM may apply one extra vote for their preferred candidates * accepted nominees remain on python-committers; others are removed No-confidence voting process ---------------------------- A vote of no confidence proceeds as follows: * a vote of no confidence email is sent to python-committers, naming the affected member of GUIDO, justifying the nomination, and optionally listing accepted PEPs that the nominator believes should be reverted * a seconding email is sent within seven days * the nominated member of GUIDO is allowed seven days to respond, after which the nominator or the seconder may withdraw * if no nominator or seconder is available, no further action is taken * voting opens immediately * each core developer may add a +1 vote (remove the GUIDO member) or a -1 vote (keep the GUIDO member) by modifying a document in a private github repository * after seven days, voting closes * if +1 votes exceed -1 votes, the GUIDO member is removed from python-committers and any nominated PEPs are reverted * if requested by the remaining members of GUIDO, or if only one member of GUIDO remains, a new election to replace the removed member may be held following the usual process. * in the case of removing the President of GUIDO, the candidate who originally received the second-most votes becomes President Examples of intended behaviour ============================== This section describes some examples of the kind of interactions that we hope to see between GUIDO and the core developers. None of these are binding descriptions, but are intended to achieve some consensus on the types of processes we expect. GUIDO candidates may campaign on the basis of whatever process they prefer, and core developers should allocate votes on this basis. Scenario 1 - The Case of the Vague PEP -------------------------------------- Often in the past, initial proposals have lacked sufficient detail to be implementable by anyone other than the proposer. To avoid this, GUIDO should read proposals "fresh" when submitted, and without inferring or using any implied context. Then, when an aspect of a PEP is not clear, GUIDO can reject the proposal and request clarifications. Since the proposal is rejected, it must be modified and resubmitted in order to be reviewed again. GUIDO will determine how much guidance to provide when rejecting the PEP, as that will affect how many times it will likely be resubmitted (and hence affect GUIDO's own workload). This ensures that the final PEP text stands alone with all required information. Scenario 2 - The Case of the Endless Discussion ----------------------------------------------- From time to time, a discussion between Python contributors may seem to be no longer providing value. For example, when a large number of emails are repeating points that have already been dealt with, or are actively hostile towards others, there is no point continuing the "discussion". When such a discussion is occurring on python-committers as part of a request for pronouncement, a member of GUIDO should simply declare the thread over by rejecting the proposal. In most known cases, discussion of this sort indicates that not all concerns have been sufficiently addressed in the proposal and the author may need to enhance some sections. Alternatively, and in the absence of any rejection from the other members of GUIDO, the President may declare the thread over by accepting the proposal. Ideally this would occur after directly confirming with the rest of GUIDO and the RM that there are no concerns among them. When such a discussion is occurring on another list, members of GUIDO should be viewed as respected voices similar to other core developers (particularly those core developers who are the named experts for the subject area). While none have specific authority to end a thread, preemptively stating an intent to block a proposal is a useful way to defuse potentially useless discussions. Members of GUIDO who voluntarily follow discussions other than on python-committers are allowed to suggest the proposer withdraw, but can only actually approve or reject a proposal that is formally submitted for pronouncement. Scenario 3 - The Case of the Unconsidered Users ----------------------------------------------- Some proposals in the past may be written up and submitted for pronouncement without considering the impact on particular groups of users. For example, a proposal that affects the dependencies required to use Python on various machines may have an adverse impact on some users, even if many are unaffected due to the dependencies being typically available by default. Where a proposal does not appear to consider all users, GUIDO might choose to use their judgement and past experience to determine that more users are affected by the change than described in the PEP, and request that the PEP also address these users. They should identify the group of users clearly enough that the proposer is able to also identify these users, and either clarify how they were addressed, or made amendments to the PEP to explicitly address them. (Note that this does not involve evaluating the usefulness of the feature to various user groups, but simply whether the PEP indicates that the usefulness of the feature has been evaluated.) Where a proposal appears to have used flawed logic or incorrect data to come to a certain conclusion, GUIDO might choose to use other sources of information (such as the prior discussion or a submission from other core developers) to request reconsideration of certain points. The proposer does not necessarily need to use the exact information obtained by GUIDO to update their proposal, provided that whatever amendments they make are satisfactory to GUIDO. For example, a PEP may indicate that 30% of users would be affected, while GUIDO may argue that 70% of users are affected. A successful amendment may include a different but more reliable percentage, or may be rewritten to no longer depend on the number of affected users. References ========== .. [1] The Spanish Inquisition, `<https://youtu.be/Ixgc_FGam3s>`_ Copyright ========= This document has been placed in the public domain.

2 years, 10 months

Python 4.0 or Python 3.10?

by Yury Selivanov

What's the current plan for what version of Python we release after 3.9? The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9. I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :) Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this. Yury

2 years, 10 months

[RELEASE] Python 3.7.1rc1 and 3.6.7rc1 now available for testing

by Ned Deily

Python 3.7.1rc1 and 3.6.7rc1 are now available. 3.7.1rc1 is the release preview of the first maintenance release of Python 3.7, the latest feature release of Python. 3.6.7rc1 is the release preview of the next maintenance release of Python 3.6, the previous feature release of Python. Assuming no critical problems are found prior to 2018-10-06, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find these releases and more information here: https://www.python.org/downloads/release/python-371rc1/ https://www.python.org/downloads/release/python-367rc1/ -- Ned Deily nad(a)python.org -- []

2 years, 10 months

Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

by Antoine Pitrou

Hi, I'm choosing to forward this to python-committers because I don't think python-ideas is a reasonable place to discuss CoC decisions. I think the action taken by Brett (apparently decided with Titus and a mysterious "conduct working group") is not the right one: - a definitive ban is an extremely strong decision that should only be taken if nothing else works. May I remind that Anatoly was able to post prolifically and unconstructively for several years, being warned several times, before being finally banned? Comparatively, this one ban seems expeditive. - the reasons given, to me, don't make sense at all. The word "n-----" is not a forbidden word if you want to describe, precisely, linguistics and the relativity of meanings (instead of actually *qualifying* someone or a groupe of people), which is what the OP claimed to do. The other reasons look like a similar kind of over-reaction. Even if something there looks inappropriate to you, it's still enough of a grey area that a ban is absolutely the wrong answer. I deduce that it's ok to say "slave" in a discussion instead of using an expression such as "the s-word". Why one term is allowed and the other, not, may be clear to Americans (or, perhaps, a large fraction thereof), but hey, it's not clear to other people around the world. Banning a (apparently) Dutch person because he doesn't understand American standards of offense is not only unfair, but it makes our community *not* inclusive of other cultures. As a French person myself, I could not, even if I wanted to, turn myself into an authentic American: what is obvious to you is not obvious to me and it would be extremely brutal and humiliating to ban me for having the wrong nationality and the wrong culture. I will ask: please consider the work and effort that it *already* takes for other people to adapt to standards of discussion that are, obviously, those of a particular culture. Otherwise you're raising barriers even more, not lowering them. At the end of it, it looks like we have a real moderation problem. python-ideas threads frequently veer out into unconstructive back-and-forths (and, well, that's not *only* the ethically-sensitive threads). The CoC is being applied erratically, sometimes precipitately, by apparently overworked and emotionally exhausted moderators, with bad consequences on the quality of the decisions. Moderators should not become emotionally exhausted (which means we need a more adequate discussion system *and* a more collegial, spread out, team of moderators); and, if they become so, I would humbly suggest it's a better idea - even if not always easy to follow - to step back and take some rest than make decisions in such a state. We also need real guidelines to the moderators as to which decision on the scale of possible decisions to apply, depending on severity of the offense / violation and on the "offendor"'s past behaviour. In the end, I hope we can set ourselves better moderation standards. As for me, I find the current situation very worrying, including for my ability to contribute constructively to Python. If I have to fear banning for every word that I say and that might be deemed inappropriate in the moderators' culture, I might just as well leave instead of feeling stressed and anguished everytime I post something. I would not want to live this in paid work: why would I endure it as a volunteer, while my main gratification should be the pleasure taken in contributing? Regards Antoine. ----- Message Transféré ----- Date : Thu, 20 Sep 2018 11:56:05 -0700 De : Brett Cannon <brett-+ZN9ApsXKcEdnm+yROfE0A(a)public.gmane.org> À : Jacco van Dorp <j.van.dorp-i74+SDIRvn1mR6Xm/wNWPw(a)public.gmane.org> Cc : python-ideas <python-ideas-+ZN9ApsXKcEdnm+yROfE0A(a)public.gmane.org> Groupe de discussion : gmane.comp.python.ideas Sujet : CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) The below email was reported to the PSF board for code of conduct violations and then passed on to the conduct working group to decide on an appropriate response. Based on the WG's recommendation and after discussing it with Titus, the decision has been made to ban Jacco from python-ideas. Trivializing assault, using the n-word, and making inappropriate comments about someone's mental stability are all uncalled for and entirely unnecessary to carry on a reasonable discourse of conversation that remains welcoming to others.

2 years, 10 months

bpo triage privileges for Karthikeyan Singaravelan

by Zachary Ware

On the recommendation of Ammar Askar and with Serhiy's endorsement on Zulip [0], I've given Karthikeyan Singaravelan (CC'd) triage privileges on bugs.python.org. Karthikeyan, please use your new-found powers for good, and don't hesitate to ask for guidance if you need it. Keep up the good work, and thank you! [0] https://python.zulipchat.com/#narrow/stream/116501-workflow/subject/bug.20t… -- Zach

2 years, 10 months

Fwd: [Python-ideas] JS’ governance model is worth inspecting

by Guido van Rossum

Perhaps worth including in PEP 8002, the overview of other governance models? (Though the process described here seems to be JS's equivalent of our PEP process -- it doesn't say anything about how TC39 gets formed or how non-technical decisions are handled.) ---------- Forwarded message --------- From: James Lu <jamtlu(a)gmail.com> Date: Fri, Sep 21, 2018 at 4:25 AM Subject: [Python-ideas] JS’ governance model is worth inspecting To: <python-ideas(a)python.org> JS’ decisions are made by a body known as TC39, a fairly/very small group of JS implementers. First, JS has an easy and widely supported way to modify the language for yourself: Babel. Babel transpires your JS to older JS, which is then run. You can publish your language modification on the JS package manager, npm. When a feature is being considered for inclusion in mainline JS, the proposal must first gain a champion (represented by 🚀)that is a member of TC-39. The guidelines say that the proposal’s features should already have found use in the community. Then it moves through three stages, and the champion must think the proposal is ready for the next stage before it can move on. I’m hazy on what the criterion for each of the three stages is. The fourth stage is approved. I believe the global TC39 committee meets regularly in person, and at those meetings, proposals can advance stages- these meetings are frequent enough for the process to be fast and slow enough that people can have the time to try out a feature before it becomes main line JS. Meeting notes are made public. The language and its future features are discussed on ESDiscuss.org, which is surprisingly filled with quality and respectful discussion, largely from experts in the JavaScript language. I’m fairly hazy on the details, this is just the summary off the top of my head. — I’m not saying this should be Python’s governance model, just to keep JS’ in mind. _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido)

2 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers September 2018