[Python-Dev] PEP 565: Show DeprecationWarning in main (original) (raw)

Victor Stinner victor.stinner at gmail.com
Wed Dec 6 04:42:41 EST 2017

Let's discuss -Xdev implementation issue at https://bugs.python.org/issue32230

In short, -Xdev must add its warning at the end to respect BytesWarning, whereas it's not possible with -W option :-(

Victor

Le 6 déc. 2017 09:15, "Nick Coghlan" <ncoghlan at gmail.com> a écrit :

On 6 December 2017 at 14:50, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 6 December 2017 at 14:34, Nick Coghlan <ncoghlan at gmail.com> wrote:

That said, I go agree we could offer easier to use APIs to app developers that just want to hide warnings from their users, so I've filed https://bugs.python.org/issue32229 to propose a straightforward "warnings.hidewarnings()" API that encapsulates things like checking for a non-empty sys.warnoptions list. I've updated the "Limitations" section of the PEP to mention that separate proposal: https://github.com/python/peps/commit/6e93c8d2e6ad698834578d4077b92a 8fc84a70f5

Having rebased the PEP 565 patch atop the "-X dev" changes, I think that if we don't change some of the details of how -X dev is implemented, warnings.hide_warnings (or a comparable convenience API) is going to be a requirement to help app developers effectively manage their default warnings settings in 3.7+.

The problem is that devmode doesn't currently behave the same way -Wd does when it comes to sys.warnoptions:

$ ./python -Wd -c "import sys; print(sys.warnoptions);

print(sys.flags.dev_mode)" ['d'] False $ ./python -X dev -c "import sys; print(sys.warnoptions); print(sys.flags.dev_mode)" [] True

As currently implemented, the warnings module actually checks sys.flags.dev_mode directly during startup (or sys._xoptions in the case of the pure Python fallback), and populates the warnings filter differently depending on what it finds:

$ ./python -c "import warnings; print('\n'.join(map(str,

warnings.filters)))" ('default', None, <class 'DeprecationWarning'>, 'main', 0) ('ignore', None, <class 'DeprecationWarning'>, None, 0) ('ignore', None, <class 'PendingDeprecationWarning'>, None, 0) ('ignore', None, <class 'ImportWarning'>, None, 0) ('ignore', None, <class 'BytesWarning'>, None, 0) ('ignore', None, <class 'ResourceWarning'>, None, 0)

$ ./python -X dev -c "import warnings; print('\n'.join(map(str,

warnings.filters)))" ('ignore', None, <class 'BytesWarning'>, None, 0) ('default', None, <class 'ResourceWarning'>, None, 0) ('default', None, <class 'Warning'>, None, 0)

$ ./python -Wd -c "import warnings; print('\n'.join(map(str,

warnings.filters)))" ('default', None, <class 'Warning'>, None, 0) ('default', None, <class 'DeprecationWarning'>, 'main', 0) ('ignore', None, <class 'DeprecationWarning'>, None, 0) ('ignore', None, <class 'PendingDeprecationWarning'>, None, 0) ('ignore', None, <class 'ImportWarning'>, None, 0) ('ignore', None, <class 'BytesWarning'>, None, 0) ('ignore', None, <class 'ResourceWarning'>, None, 0)

This means the app development snippet proposed in the PEP will no longer do the right thing, since it will ignore the dev mode flag:

if not sys.warnoptions:
    # This still runs for `-X dev`
    warnings.simplefilter("ignore")

My main suggested fix would be to adjust the way -X dev is implemented to include sys.warnoptions.append('default') (and remove the direct dev_mode query from the warnings module code).

However, another possible way to go would be to make the correct Python 3.7+-only snippet look like this:

import warnings
warnings.hide_warnings()

And have the forward-compatible snippet look like this:

import warnings:
if hasattr(warnings, "hide_warnings"):
    # Accounts for `-W`, `-X dev`, and any other implementation

specific settings warnings.hide_warnings() else: # Only accounts for -W import sys if not sys.warnoptions: warnings.simplefilter("ignore")

(We can also do both, of course)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171206/2d3d848d/attachment.html>

More information about the Python-Dev mailing list