[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Nick Coghlan]

On 9 November 2017 at 04:56, Barry Warsaw <barry at python.org> wrote:
> 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.)

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   |   ncoghlan at gmail.com   |   Brisbane, Australia