About `defaultdict.__missing__`

I could be persuaded that we don’t need a PEP, but we at least need this kind of public discussion to see if we need a PEP. That is, we need the kind of discussion we’re having now, and I appreciate that we’re having it. :slight_smile:

We won’t know unless we have the discussion somewhere more public than on the PR.

Maybe, but we won’t know unless we have the discussion somewhere more public than on the PR.

What I meant by “backdoor” is no so much the PR process as the sequence of events that goes:

  1. seemingly small and/or beneficial change made
  2. unexpected consequence discovered (change in behavior, divergence from documentation, etc,)
  3. the change in step 1 is considered “status quo” because it has already been made
  4. instead of undoing the change, we retcon the docs to specify the behavior that was accidentally implemented

In short, changes in behavior, and especially changes that tread close to lines of ambiguity in docs, should always be made with full awareness, not just left in because we didn’t notice the problem at the time the change was made. If something happens and we later realize it contradicts the docs, the default response should be to roll it back, and then maybe later we can think if we want to change the docs to clarify, and then maybe later reimplement the change deliberately in that context.

That said, I do think that some stuff happens in the normal PR process that should get more public discussion and in some cases a PEP. We saw this for instance with the ~bool deprecation change. In my view that change should absolutely have required a PEP.

Basically what I’m saying is that we shouldn’t let the fact that it got into a release cloud our thinking about what the right answer to the question is. If a decision was made by a few people on a PR and it turns out that decision had broader consequences and needs consideration of those consequences, the default response should be to roll back the change until we can make a fully informed decision about what behavior we actually want.

I get what you’re saying about “design by committee”, but I just feel that, because Python is so widely used, even seemingly tiny changes can wind up having unforeseen impacts. So I think the bar for some kind of discussion more public than a PR should be pretty low. In other words we can’t avoid having more design done by committee than maybe was the case in the past, because the stakes are too high to just go around changing stuff.