Guido van Rossum <gu...@python.org> added the comment: I am at a loss for words.
On Oct 12, 2017 6:27 PM, "Nick Coghlan" <rep...@bugs.python.org> wrote: > > 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 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
