On 21 July 2015 at 21:19, Paul Moore p.f.moore@gmail.com wrote:
On 21 July 2015 at 11:03, Ben Finney ben+python@benfinney.id.au wrote:
If challenged to do so, could one (the contributor) present a compelling justification for the change?
This is what I claim Paul Moore's doubt (fear?) is indicative of. I maintain that this doubt is quite healthy: it helps the contributor to pause, reflect, seek assistance in making decisions, and thereby also tends to exclude poorly-justified changes which would otherwise be committed.
That is *not* what I was trying to express. My fear is that I will be subjected to the sort of unreasonable level of debate and frankly criticism that came up in this thread, and I'm not sure if I have the energy to deal with it. I wouldn't ever commit something unless *in my judgement* it was OK to go in. Whether my judgement is sufficient is the whole point here.
Exactly. Being granted a commit bit means "The folks that got CPython to where it is today trust you to take appropriate risks in guiding CPython's future". It can be safely assumed that *everyone* that has that authority takes it *very* seriously (otherwise they wouldn't have been granted commit privileges).
If there weren't any risks to be weighed and judgment calls to be made, we could let a computer decide what commits should go in (and indeed "make patchcheck" already handles some of those basic tasks, and we'd like to automate even more of them like "does this patch apply, and do the tests still pass on x86_64 under at least Windows and a long term support Linux distro after applying it?"). This challenge is reflected in the fact that the Zen of Python is deliberately self-contradictory, as it articulates competing design principles to take into consideration, rather than being able to provide ironclad rules that avoid the need for human judgement in determining *which* of those design guidelines are most salient in any given situation.
Now, proposing further *enhancements* to a change is perfectly reasonable, especially if the feedback is based on practical experience with the original version of the change. The implementation of PEP 492 (async/await), for example, underwent some fundamental changes during the beta process, as developers' feedback showed that some of the design decisions we made in the original version were quite problematic. The original exception suppression mechanism in PEP 409 (which made clever-but-idiosyncratic use of Ellipsis), was replaced with the simpler mechanism in PEP 415 (which instead uses a more conventional setter-with-side-effects-on-other-attributes approach).
Reverting changes because they broke the buildbots, or because they're determined to cause bugs worse than the original problem is also not a problem - in those cases, there's new information introduced into the situation that changes the original risk assessment. An example of that was deciding to deprecate and remove contextlib.nested() before I'd figured out how to replace its legitimate use cases - I'd flat out missed a fundamental problem with the way it interacted with open() and similar resource allocation functions.
The draining and demotivating cases are the ones where *no new information is introduced*, but the design decision is *challenged anyway*. Those are the ones that feel like folks are saying "We don't *actually* trust you with that authority and responsibility you've been granted, so we're going to closely police the way you use it, and expect to be able to persuade you to change your mind not through reasoned argument, but through sheer volume".
For new core developers, or folks aspiring to become core developers, it is *literally* the scenario that inspired Poul-Henning Kamp to write the post at http://bikeshed.org/ (hit refresh if you get a low contrast colour scheme, it will change). Don't bother trying to improve anything, you'll just get grief and opposition for it rather than community support.
For experienced core developers, it's a "Right, so you trust me to build the nuclear power plant, but not to choose the colour of the bike shed behind it" situation. Knowing we're trusted to build power plants, but will get grief for working on smaller things creates an even greater incentive to work solely on the big changes, and those are already inherently more fun to work on anyway - they really don't need the extra help.
Regards, Nick.