[Python-Dev] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language. We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient. At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received little support from core developers. PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax, although the SC understands the desire to improve those aspects of the Pattern Matching proposal. Regarding that, we would also like to mention that changes building on top of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be submitted via the PEP process for review using the regular channels (discussions in python-dev or the https://discuss.python.org/ server), followed by a formal submission to the Steering Council for consideration, taking into account that backwards-incompatible changes can only be made before the feature freeze point of Python 3.10. See PEP 619 (https://www.python.org/dev/peps/pep-0619/) for details on the release schedule for Python 3.10. We know that Pattern Matching has been a challenging feature that has sparked considerable discussions and design conversations, leading to several revisions from feedback stemming from the community, core devs, and the Steering Council. We are very happy to see that the Python developer community remains passionate and respectful, and we are sure that the result has benefited a lot because of it. Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel, Talin, and everyone that participated in the discussion and implementation of this important new feature! -The Python Steering Council ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 651, Robust Stack Overflow Handling, Rejection notice
Hi Mark, Thank you for submitting PEP 651. The Steering Council has spent the past two weeks reviewing PEP 651. After careful consideration, we have decided to reject the PEP. The following were the key points that led us to this decision: * The benefits are not compelling enough. Deep recursion is not a common tool in Python, and even with PEP 651 it would not be efficient enough to make it a common tool. * The benefit of PEP 651 is negated as soon as a non-Python function is involved in the recursion, making the likelihood of it being useful even smaller. It also creates easy pitfalls for users who do end up relying on recursion. * We believe the PEP understates the disruption created by the technical solution of multiple Python stack frames per C call. Although this may be solvable, it will certainly cause substantial disruption to existing debuggers, tracers, and state inspection tools as they need to adapt to this change (which may not be trivial). * As the way to approach this will be platform-specific (as some parts of the proposal are not portable), this can cause generic Python code to behave differently on different platforms, making this kind of code less portable and less predictable. In the end, the benefit of the PEP does not outweigh the cost of the potential breakage, confusion, and unpredictability of the feature. With our appreciation, The Python Steering Council ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/75BFSBM5AJWXOF5OSPLMJQSTP3TDOKRP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Steering Council reply regarding conduct (was Re: Steering Council update for February)
From Thomas Wouters, on behalf of and with full support of the Python Steering Council: I’ll post a separate reply about the merits of the decision, but we have to talk about this post from Steven D’Aprano in particular. Steven, this reply -- its tone and its message -- are completely unacceptable. It is offensive, dismissive and insulting. It’s a bad faith argument ridiculing a good faith effort. It is particularly insulting that you take the time to draw false equivalences to arguments that weren’t made on this list, and that you’re assuming motivation and ridiculing it, without taking the time to engage in the actual arguments. There are plenty of sources online that you could’ve used to learn more, or you could have just asked in this thread. Instead, you posted this sarcastic, denigrating, mocking reply. Yours isn’t the only post that crosses the line in this thread, but it is the worst. It is an example of the kind of discourse that is too common and that reflects very badly on python-dev. It creates an atmosphere of disrespect and abuse, and actively scares away both experienced contributors and new ones. This is not conjecture; I and others on the SC have heard from more than a dozen people that this is exactly the case. This is not acceptable. It has to stop. The PSF Code of Conduct WG has sent the SC a recommendation on this issue. It recommended a temporary ban from python-dev for Steven, and a warning for someone else. While the SC believes a temporary ban would certainly be a reasonable action, we decided to instead make this public statement, as a warning to everyone. The SC wants to be clear that this statement applies to everyone who has made uncivil and inflammatory posts. This tone is not acceptable from anyone. The SC wants to make this very clear: this is a final warning to remind everyone that this behaviour will result in strong measures, including bans and ejections. If you want to argue something, do so on the merits, in good faith, and with empathy and consideration. If you can only ridicule someone, their motivation or their lived experience, please keep it to yourself. > On Tue, Mar 09, 2021 at 08:27:19PM +, Pablo Galindo Salgado wrote: > > >The Steering Council discussed renaming the master branch to main and > >the consensus was that we should do that. > > And about time too. Can we now tackle some of the equally pressing use > of offensive terms that are common in the Python community, starting > with the name of the language itself? > > Pythons are snakes, which is triggering to people with a phobia of > snakes. About one third of all people, or more than two *billion* > people, suffer from some level of phobia towards snakes. > > The popular "nose" testing framework is a blatant antisemetic and > neo-nazi dog whistle. > > "bool" is named after George Boole, a problematic white man who > appropriated the culture of both the Middle East and East Asia. > > "dict" is confusable with, and is often abbreviated to, an offensive > word. And don't even get me started with the obvious sexism of "tty". > > Unicode is racist because it has unified Chinese, Japanese and Korean > characters as if they were the same thing, and relegates non-Western > languages to second class status: > > https://modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-cant-write-my-name > > It also includes a teddy bear symbol, which is named after notorious > racist and imperialist Theodore Roosevelt, and no less than *six* > swastika symbols. Also the Cross of Jerusalem, the symbol of such openly > fascist groups as the Federal State of Austria during the 1930s and the > Russian far-right extremist organisation the People's National Party. > > It even has a symbol for chains, which is associated even more closely > with slavery than "master". > > Speaking of slavery, in the standard library we have ChainMap and > itertools.chain. > > We have the ableist "runpy", and in the random module a function named > after Vilfredo Pareto, who supported the rule of fascist dictator Benito > Mussolini. There are the token and tokenize modules, which are offensive > for their association with both sexist and racist views. > > The tarfile module is associated with the racist Uncle Remus stories, > and a derogatory term for US Blacks. > > https://www.washingtonpost.com/blogs/compost/post/doug-lamborns-tar-baby-quagmire/2011/08/03/gIQAKmXnsI_blog.html > > The textwrap module uses a derogatory racist and fatphobic term dozens > of times. > > http://rsdb.org/slur/chunk > > Each of these issues are just as important as the "master" issue. > > > -- > Steve ___
[Python-Dev] On the migration from master to main
From Thomas Wouters, on behalf of and with full support of the Python Steering Council: This discussion seems to have died down a little, but I still want to make a few things clear: Yes, this is a political decision. Very many decisions are political. The existence of an open-source project is inherently political. The decision to try and make python-dev more welcoming, more open, more helpful is also a political decision -- one that the SC feels is absolutely necessary for the long-term health of the Python language. Not wanting to be bothered by political decisions is a political decision; it’s a decision that you’re happy with politics as they are. I’m afraid you can’t avoid politics. This isn’t just about ‘master’ being rooted in slavery. This is about what the community sees and does. As I mentioned before, we’re not leading the pack in this, we’re merely following along with others (like, say, Django). There are undoubtedly other terms and practices that are genuinely offensive, and the decision on how to handle them will be taken on a case-by-case basis, weighing the cost and the benefit in each case. While you may feel the benefit of this change is small and that it has no real impact, we believe that there is little cost to making this change. We believe this change, while a minor inconvenience to some, helps demonstrate our commitment to acting in the best interests of Python's future. Failure to make a small sacrifice, such as this, signals that the Python core development community would be unlikely to undertake real change for greater benefits. This isn’t happening because GitHub/Microsoft made a political decision. It’s happening because it is incredibly easy to make this move, many projects have already done this, and it reflects badly on any project not making this change. Speaking for the whole SC in this, Thomas. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/J5GR6YVIVWQ2VPLISAGBQH3UQN4YWAXS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Official joint communication from the Python Steering Council, PSF Board of Directors, and PSF Conduct WG
Recently, a series of discussions on this mailing list resulted in behavior that did not live up to the standards of the Python Community. The PSF Board of Directors, Python Steering Council, and the PSF Conduct Working Group would like to remind this community that our shared goal is to advance the Python language while simultaneously building a diverse, inclusive, and welcoming Python community. While the community has made progress in recent years, this discussion made it clear to many of us that we still have room to grow. At the request of the PSF Board, the Steering Council, and members of the community, the PSF Conduct WG met to discuss these recent events and recommend action. As a result, warnings will be given to several members of the Python Community, and the Steering Council will be taking further action. Especially during passionate discussions like these, we'd like to ask that all Pythonistas focus on being welcoming and respectful, and that we all try to act in the best spirit of the Python Community. Thank you, Python Steering Council PSF Board of Directors PSF Conduct WG ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5NMO2XKYLCNUT7BTMIFQOPF57FDXLHTQ/ Code of Conduct: http://python.org/psf/codeofconduct/
