On 9 November 2017 at 04:56, Barry Warsaw <[email protected]> wrote:
> On Nov 8, 2017, at 08:47, Guido van Rossum <[email protected]> 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.)
I did see that, but I think a "once::DeprecationWarning:__main__"
filter provides a comparable benefit in a simpler way, as the
recommended idiom to turn off deprecation warnings at runtime becomes:
from elsewhere import main
if __name__ == "__main__":
import sys
sys.exit(main(sys.argv))
That same idiom will then work for:
* entry point wrapper scripts
* __main__ submodules in executable packages
* __main__.py files in executable directories and zip archives
And passing "-Wd" will still correctly override the default filter set.
It doesn't resolve the problem Nathaniel pointed out that "stacklevel"
can be hard to set correctly when emitting a warning (especially at
import time), but it also opens a new way of dealing with that: using
warnings.warn_explicit to claim that the reporting module is
"__main__" if you want to increase the chances of the warning being
seen by default.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
