Hang on, I was responding to a comment that said that autoformatters helped address the problem where people wrote a PR that got rejected by code format checking CI! I’m so used to pip’s CI that I seem to have misremembered - you’re saying that core CPython doesn’t have CI checks for code style right now?
So in the absence of code format checks (i.e., where CPython’s codebase is right now) the only reason PRs get blocked for code style is because some core developer felt that they wanted to request style changes? Why is this even a problem? Do we have core devs who style check code purely on the basis of a mechanical application of the PEP 8 rules, rather than by judging that something isn’t readable? Then we should be discussing with them whether their review approach is helpful. Do we have PR submitters who refuse to address reasonable readability improvement requests? Then we should discuss with them and educate them, not hit them with the hammer of “the rules say so”. Do we have core developer arguments over what’s best style? If so then we should lighten up, and/or agree a consensus (or check PEP 8 to see if we already have a consensus )
Re-reading the “Motivation” section of the proposal with my new understanding that we don’t currently enforce CI checks for style, I see very little explanation of why we need any automated validation that PEP 7/8 are followed in the first place. It reads as if mechanically checking is self-evidently a good thing, and concentrates on “not making core devs do that mechanical check” as the benefit. But the premise there (that mechanical application of the style rules is required) is never justified, and is, in my view, both wrong and in violation of PEP 8’s comment that human judgement should always override blindly applying rules.