[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: We found an agreement with Nick :-) I applied Nick's PR. The issue is now fixed: vstinner@apu$ ./python -X dev -c 'import sys; print(sys.warnoptions)' ['default'] This PR also fix bpo-20361: -b and -bb options now have the highest

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: New changeset 747f48e2e92390c44c72f52a1239959601cde157 by Victor Stinner in branch 'master': bpo-32230: Set sys.warnoptions with -X dev (#4820) https://github.com/python/cpython/commit/747f48e2e92390c44c72f52a1239959601cde157

[issue32230] -X dev doesn't set sys.warnoptions

Change by STINNER Victor : -- pull_requests: +4710 ___ Python tracker ___ ___

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: "-W options > PYTHONWARNINGS > BytesWarning > -X dev > default filters" Hum, sorry, according to bpo-20361 (and bpo-32231 which has been marked as a duplicate of bpo-20361), -b and -bb options must have the priority over

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: If we wanted to go that way, then I'd go back to my original code order for - putting the '-X dev' setting first in sys.warnoptions, so both PYTHONWARNINGS and -W options override it. Then https://bugs.python.org/issue32231 would determine

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: I prefer to not talk about sys.warnoptions since, as you wrote, the order is reversed. IMHO the priority should be (high priority > low priority): -W options > PYTHONWARNINGS > BytesWarning > -X dev > default filters With: *

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: Right, I hit some of those corner cases myself before I realised that pymain_add_warnings_options was the right place to inject "default" into sys.warnoptions after your refactoring improvements. It provides a nice pivot point where the

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: > It isn't good to have "-X dev" do magical things that can't already be > replicated with other options. While it might be nice to be able to replicate -X dev "manually", I didn't try to implement that. The current implementation

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: In relation to the utility of sys.warnoptions: it also lets other modules (like the unittest module) inspect the warnings that have been specified on the command line. If it wasn't for that use case, I wouldn't be concerned about the fact

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: No, we don't need to worry about BytesWarning if neither -b nor -bb are set, as the interpreter doesn't even emit the warning in that case. The only thing the warnings machinery gets used for is to print the messages and/or raise the

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: First I proposed that -X dev behaves as -Wd -b, but Antoine Pitrou and Serhiy Storchaka asked to remove -b: https://mail.python.org/pipermail/python-dev/2017-November/150517.html

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: I filed https://bugs.python.org/issue32231 to cover having -bb always override other warnings settings when it comes to handling BytesWarning. Writing that issue made me realise another quirk with `-X dev` though: as a command line option,

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: > If we want "-bb" to take precedence over the passed in "-W" settings It's not only that. Without -b nor -bb, the default::Warning filter should still come after ignore::BytesWarning, since these warnings must be ignored by

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: It isn't good to have "-X dev" do magical things that can't already be replicated with other options. If we want "-bb" to take precedence over the passed in "-W" settings (which I agree would be a reasonable change), we should make that

[issue32230] -X dev doesn't set sys.warnoptions

Change by Nick Coghlan : -- keywords: +patch pull_requests: +4637 stage: test needed -> patch review ___ Python tracker ___

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: I was explicitly asked to not change the behaviour of BytesWarning with -X dev. -X dev documentation doesn't menton -Wd/-Wdefault anymore: https://docs.python.org/dev/using/cmdline.html#id5 "Warning filters: add a filter to display

[issue32230] -X dev doesn't set sys.warnoptions

Nick Coghlan added the comment: Note that this change will make "-X dev" effectively treat "-bb" and "-b" as equivalent, the same way "-Wd" already does. I figure that's OK, since it means the runtime behaviour will match the documentation (which says that "-X dev"

[issue32230] -X dev doesn't set sys.warnoptions

STINNER Victor added the comment: I did it on purpose. -Wdefault adds the filter at the start, whereas -Xdev adds the filter at the end to respect BytesWarning. See tests in test_cmd_line and bpo-32089. -- ___ Python

[issue32230] -X dev doesn't set sys.warnoptions

New submission from Nick Coghlan : The `-X dev` option is currently integrated directly with the warnings module, rather than working indirectly through `sys.warnoptions`. This means that any third party code that currently checks sys.warnoptions will need to be updated to