On Nov 8, 2017, at 08:47, Guido van Rossum <guido at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://mail.python.org/pipermail/python-dev/attachments/20171108/1d455e77/attachment.sig>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4