On Tue, Mar 22, 2022 at 4:36 PM Barry Warsaw <ba...@python.org> wrote:
> PEP 2 will have to be “un-superseded”, and presumably the devguide (which > PEP 2 points to) will also need to be updated. > we discussed that a bit. the dev guide makes sense as a "how to do it" purpose document, useful for constructing PRs. The PEP makes sense as a "here's the policy before merging or spending too much time on it". they'd link to each other, but they have distinct roles. > > I think it’s probably fine to drop the idea of provisional APIs. Aside > from the limit benefit of evolution within the stdlib, code still gets > written against provisional APIs and people still complain when they break > in non-backward compatible ways, so we might as well avoid the whole thing. > > -Barry > > > On Mar 22, 2022, at 16:26, Brett Cannon <br...@python.org> wrote: > > > > I had kicked off a discussion a while back at > https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681 > about how to manage the stdlib (this has nothing to with what the stdlib is > and thus what belongs in it). It finally bubbled up in the SC agenda and > after discussing things we have three proposals: > > • Update PEP 2 to say a PEP is necessary to add a module to the > stdlib > > • Update PEP 4 to say that a PEP is necessary to deprecate/remove > a module > > • Mark PEP 411 as obsolete and thus dropping the idea of > provisional modules > > The PEP requirements are because the stdlib is important to manage > appropriately and since it's a shared resource it should be something we > all discuss. The PEP process seems like a good mechanism for both keeping > what we bring in under control while also making sure people don't break > people's code needlessly with removals. > > > > The dropping of the concept of provisional modules is from simply having > not seen any true benefit that could have been had in other ways (e.g. > typing, asyncio, importlib.metadata). In pretty much all cases the APIs > could have evolved publicly first and then been brought into the stdlib > once stable (if at all), so the concept of "provisional" just doesn't seem > worth keeping around. > > > > We wanted to see if there was consensus around any of these ideas, hence > this email. 🙂 > > _______________________________________________ > > python-committers mailing list -- python-committers@python.org > > To unsubscribe send an email to python-committers-le...@python.org > > https://mail.python.org/mailman3/lists/python-committers.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > _______________________________________________ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/SKD3XJQF44F2BB6BCCACCPDZDRWTCSWC/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ >
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/GQKYSLUAZRS2H2DPU7ONFUOPJNO5BARO/ Code of Conduct: https://www.python.org/psf/codeofconduct/
