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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
