I hadn't seen that, but it requires too much cooperation of library owners.
On Wed, Nov 8, 2017 at 10:56 AM, Barry Warsaw <ba...@python.org> wrote: > On Nov 8, 2017, at 08:47, Guido van Rossum <gu...@python.org> wrote: > > > > You seem to have missed Nick's posts where he clearly accepts that a > middle ground is necessary. R D Murray is also still unconvinced. (And > obviously I myself am against reverting to the behavior from 7 years ago.) > If we can't agree on some middle ground, the status quo will be maintained. > > I haven’t seen a response to my suggestion, so it’s possible that it got > missed in the flurry. With coordination with setuptools, we could: > > * Re-enable DeprecationWarning by default > * Add a simplified API for specifically silencing DeprecationWarnings > * Modify setuptools to call this API for generated entry point scripts > > I think this would mean that most application users would still not see > the warnings. The simplified API would be available for handcrafted > scripts to call to accomplish the same thing the setuptools enhancement > would provide. Developers would see DeprecationWarnings in their > development and test environments. > > The simplified API would be the equivalent of ignore::DeprecationWarning, > so with some additional documentation even versions of applications running > on versions of Python < 3.7 would still have an “out”. (Yes, the > simplified API is just a convenience moving forward.) > > Cheers, > -Barry > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
