Nick Coghlan <ncogh...@gmail.com> added the comment: If a proposed standard library API is sufficiently stable that the folks proposing it are reluctant to emit a runtime warning about any remaining stability risks, then I think it's reasonable to expect them to propose it as non-provisional and accept the related backwards compatibility obligations.
We have past examples of our being able to cope with that approach, such as when contextlib.nested turned out to be broken at a design level, so we deprecated it, removed it, and replaced it with a combination of contextlib.ExitStack and native support for multiple context managers in with statements. Framing that in different terms: with PEP 411 as currently written, the benefits of instability accrue to the API publisher and willing early adopters, while the costs appear as negative externalities affecting folks that would prefer not to care about the API at all until it is covered by the regular backwards compatibility guarantees. This RFE proposes to internalise some of those costs (in the form of a required runtime warning for any future provisional APIs), such that API publishers ask themselves "Do I *really* need this whole API to be provisional? Can I restructure it so only selected clearly identifiable parts are provisional or private, and the rest are covered by regular stability guarantees?" and early adopters ask themselves "Do I really want to make this a *required* dependency? Perhaps I can make it optional somehow, so folks that aren't using these features won't get the warning?" ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
