On 29 July 2015 at 00:17, Ben Finney <ben+python@benfinney.id.au> wrote:
I've made a clear distinction between the need to *be able to* justify a change, versus arbitrary demands to do so by arbitrary members.
The latter is what you're arguing against, and of course I agree. I've never advocated that.
The thing we work toward as core developers, and aspiring core developers, is good design intuition that aligns with the Zen of Python. That doesn't mean we're all going to be able to perfectly *articulate* that intuition in every case, and even when we can, those explanations are themselves generally going to be backed by intuition rather than rigorous scientific research. Perhaps we need a new initialism to summarise these kinds of cases in a way that isn't dismissive of the concerns of folks that still have doubts about a decision: LTIASHIG (Let's Try It And See How It Goes) It's important to remember that *having* good design intuition is a *separate* skill from *explaining* design intuition well. The former involves being able to bring personal experience to bear on a design task, and produce a result that a non-trivial subset of people enjoy using. The latter involves things like learning a lot more about human cognition, and why certain concepts cause the human brain to get jammed up, and how the way a programming language models a particular domain relates to how folks learn about that domain in the first place. One of the best engineers I ever worked for (my first full-time boss) had *brilliant* design instincts, but was substantially weaker when it came to explaining the rationale for his decisions. Spending a few years figuring out why the software architecture he designed was such a good one turned out to be one of the most valuable learning experiences of my life (and, not coincidentally, was my original exposure to the "communicating sequential processes" approach to concurrency and parallelism). CPython core developers have *real authority* as *individuals* over a language ecosystem used by millions of people. That's a large part of why we're relatively cautious about handing out commit bits - it's not just about the technical aspects, it's about developers' design judgment, and intuitions on when things should be escalated for wider discussion *before* making a decision. Sometimes that intuition is going to tell us "this change is worth the risk, even though I can't fully explain why I think that, and hearing further opinions without supporting evidence isn't going to change my mind" . Having someone willing to make that kind of call is one of the big reasons modules with an active lead maintainer can more readily evolve than the collectively maintained modules that don't have an authoritative voice guiding their API design. And when we make genuine design mistakes (as we inevitably will)? That's one of the things the deprecation process is for: if a mistake is actively causing problems for folks attempting to use a feature, then we have options to deal with it, rather than having to carry it forever. In many cases, we can even go with a better approach, where changing our minds later involves making a *backwards compatible API change*, reducing the practical long term design risk of postponing a particular aspect of a decision to near zero. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia