Oh wow.
There were a lot of things I was expecting to hear in this discussion but this wasn’t one of them — that pip users/community is not a largely representative sample of CPython users/community — especially followed up by using that as an explanation for how pip’s efforts at change/community management don’t translate in any way whatsoever to CPython.
I’m gonna step away from this conversation now, largely because of one individual.
Between suggesting crowdfunding for standard library maintenance immediately after explaining to me1 about how funding for OSS projects is complex + difficult, using a jest-y tone to seemingly dismiss my point that a proposed discussion style is too expensive (which I can only read as joking that I don’t know that planning takes effort), not answering direct questions about what the expectations are about downstream use of provisional modules, and the use of a generally dismissive tone in replies to me — I don’t have the energy to politely respond to @steven.daprano anymore in this discussion and am gonna step away instead.
1 Based on the fact that it’s a reply to my post + the use of email etiquette on all his responses.
Anyway, I was gonna read through and summarise If Python started moving more code out of the stdlib and into PyPI packages, what technical mechanisms could packaging use to ease that transition? in a few paragraphs, PEP-style, talking about the approaches discussed and trade offs — which someone else can pick up now if they’d like to. I think it’ll be useful, since most folks here aren’t going to be reading that whole discussion to establish a common understanding of the proposal.
IMO it’s the best of all the approaches discussed so far and the only approach that replaces the provisional modules concept — which is a problematic concept, if I’m reading the room correctly.