On Fri, 26 Jun 2020 at 02:42, Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > > > it is hard to make a decision between the pros and cons, > > when the pros are in a single formal document and the > > cons are scattered across the internet. > > Mark, I support your idea. It is natural for PEP authors to not fully > articulate the voices of opposition or counter-proposals. > The current process doesn't make it likely that a balanced document is > created for decision making purposes.
I agree that the case against a PEP can often be fragmented and harder to follow than the case *for* the PEP. My impression, though, is that this more often results in PEPs *failing* to get accepted, because there's a general sense of "consensus hasn't been reached" rather than a specific set of problems with the proposal. One point that's not clear - would an Anti-PEP be *required*? If not, what should be the implication of a PEP not having one? That the objections shouldn't matter? That the PEP delegate can skip the work of reviewing discussions? In that case, fear of no-one stepping up to write an Anti-PEP could easily make the debate more contentious, rather than more reasoned. I have two particular issues: 1. Fragmented lack of consensus *can be* a valid problem with a PEP. Expecting a focused document against a PEP may be unreasonable in such cases - no one person may be sufficiently motivated to collect opinions, summarise objections and write a document, but nevertheless the *consensus* may well be against the PEP. Think of this as a variant of "status quo wins" - the onus should not be on the people arguing for "no change" to present a compelling, structured argument. You can of course object to the principle of "status quo wins" - that itself isn't set in stone, but it's a much bigger question about how we want Python to develop. 2. In practice, PEPs that spawn large debates and general, unfocused objections, have a mixed track record. Some get accepted, others get rejected. Unfortunately, it's not immediately obvious that the distinguishing factor is *solely* technical merit. There's a large element of how good authors are at presenting their case, influencing key community members, etc. This proposal seems to me to take that situation and make it worse - now we have both the PEP and its Anti-PEP, each competing not only on technical points, but also on the "people skills" of the respective authors. So while I think we should look at ways of improving this aspect of the PEP process, both to ease the workload of the PEP delegate and to ensure that PEP authors with weaker "people skills" don't get under-represented, I'm not sure the Anti-PEP is the way to go. Paul _______________________________________________ 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/JLSBHHH33Y2RB6O5DWZYGH2675SGTHZH/ Code of Conduct: http://python.org/psf/codeofconduct/
