Various PEPs: fix typos

[hauntsaninja]

Apologies if unwelcome!

[CAM-Gerlach]

As a general suggestion, if this sort of thing should be done, it would really be best to automate it or have a set process for doing so, as implemented in #2151 . Otherwise, while certainly not intended by @hauntsaninja , unfortunately these sort of wide-ranging trivial fix PRs unfortunately tend to result in needless merge conflicts with existing ones, as this one did with, e.g. #2207 , #2200 , etc. (which already would have fixed the issues identified in that PEP), plus pinging lots of codeowners for review.

[gvanrossum]

There's a lot of controversy around this, but personally I am against fixing typos unless they reduce readability. Most typos don't hamper readability much less than many other "defects" in our documentation, like poor wording, unclear examples, and outright ambiguities. We receive way fewer fixes for those quality issues. To me this is proof that a lot of contributors prefer the quick win of a typo fix over something that requires thinking, and I don't want to encourage that sort of thing. (Though I suspect in this case there's something else, because I know the OP and he's not afraid of deep thinking -- rather the opposite. :-)

[CAM-Gerlach]

Yeah; FWIW I'd more precisely specify my personal perspective as leaning against PRs with typo- and other relatively trivial fixes that impact multiple PEPs and/or don't make other more substantive/meaningful changes to the PEP(s) in question (unless the typo is in actual code, examples or makes a significant difference in meaning/correctness). I say this having initially somewhat leaning on the other side of this issue, given it had come up on some of my own work here in the past, but I've now seen firsthand some of the tangible negative consequences for these sorts of cases: merge conflicts on multiple PRs here I'm involved with, pinging a whole raft of PEP authors, and having seen some of the more substantive ambiguities on other PEPs and have them negatively impact my work on PEP 639.

Ideally it would be nice to have automated common misspelling detection/fixing as part of pre-commit and enforced on CI as in #2075 , which would solve the issue at its source and permanently moot any need for these sort of PRs. However, given it seems on that PR the non-zero overhead for contributors and maintainers/PEP editors was felt to outweigh the modest practical benefits, it would seem better to not do these sorts of PRs at all, aside from as an opportunistic part of more meaningful fixes/copyediting, etc, to specific PEPs.