On 7/29/19 4:33 AM, Paul Moore wrote:
On Sat, 27 Jul 2019 at 03:51, Kyle Stanley <aeros167@gmail.com> wrote:
In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future. Do most of the other core developers also share this perspective? Even
Eric V. Smith wrote: though PEPs were not intended to be intimidating, they definitely can be for those who are less familiar with the process. I can imagine that many people would think that a "sponsor" would mean fully convincing someone to be completely on board with their idea. Personally, my position is a bit more nuanced. I'm happy enough to sponsor a PEP, but most people's "PEP ideas" are actually still insufficiently well thought out to be worth a PEP, and typically my first comment as a sponsor would be "you don't need a sponsor yet, you need to refine your proposal a lot first". However, from the way a lot of threads on python-ideas go, it's clear that a lot of people aren't really aware of how much work is needed to get a proposal to the point where it's ready for a PEP (and when they get feedback to that effect from the list, they get frustrated at the "negative feedback").
So while I'm happy enough to sponsor a (well-written) PEP, I'm not anywhere near as willing to mentor someone in how to develop a proposal to the point where it's ready for submission as a PEP (because I simply don't have the time). And people tend not to appreciate the difference between those two tasks.
Paul
I would say that most people don't easily understand that there is by necessity (and how much) a lot more work to change a 'Standard' that affects a lot of people vs changing the local rules for a given small group or project. With a small group, it is easy to chat with most of the users and confirm that there are no obvious problems. The small group is also much more likely homogeneous in style and application, so much easier to see what it might break. When changing something much broader, there WILL be people using it in ways you just haven't thought about, and because you likely can't talk to everyone who will be affected (they aren't all listening to the same channel) it become important to work out more of the details so people not as familiar with what you are proposing can perhaps notice issues with what you are proposing. It isn't just something about Python and PEPs, but a common problem for any large scale project. -- Richard Damon