Sgtm Sent from my comm
On Mar 22, 2022, at 21:31, Gregory P. Smith <[email protected]> wrote: On Tue, Mar 22, 2022 at 4:36 PM Barry Warsaw <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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 -- > [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ _______________________________________________ python-committers mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SKD3XJQF44F2BB6BCCACCPDZDRWTCSWC/ Code of Conduct: https://www.python.org/psf/codeofconduct/ _______________________________________________ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/GQKYSLUAZRS2H2DPU7ONFUOPJNO5BARO/ Code of Conduct: https://www.python.org/psf/codeofconduct/
_______________________________________________ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/UA3LI6KLQC3ECKFHYRXLSV3VG7XOMUAV/ Code of Conduct: https://www.python.org/psf/codeofconduct/
