bpo-32230, bpo-20361: Set sys.warnoptions for all command line options #4734
Conversation
Rather than supporting dev mode directly in the warnings module, this instead adjusts the initialisation code to add an extra 'default' entry to sys.warnoptions when dev mode is enabled. This ensures that dev mode behaves *exactly* as if `-Wdefault` had been passed on the command line, including in the way it interacts with `sys.warnoptions`, and with other command line flags like `-bb`.
Lib/test/test_cmd_line.py
Outdated
|
|
||
| out = self.run_xdev("-c", code) | ||
| self.assertEqual(out, | ||
| "default::Warning " |
There was a problem hiding this comment.
default::Warning must come after BytesWarning. See also the discussion on https://bugs.python.org/issue32230
There was a problem hiding this comment.
I'll add a comment pointing out that Py_BytesWarningFlag means this filter is pretty redundant when neither -b nor -bb is passed.
|
When you're done making the requested changes, leave the comment: |
As a command line setting, dev mode should take precedence of the PYTHONWARNINGS environment variable.
|
89960ef explains why the relative order of the "ignore" BytesWarning filter doesn't really matter in practice. As mentioned in https://bugs.python.org/issue32231, I'd actually like to start leaving it out entirely in cases where it doesn't matter. |
|
I would prefer to also fix https://bugs.python.org/issue20361 in this PR to fix all warnings options priority at once: Otherwise, I expect a temporary regression until https://bugs.python.org/issue20361 is fixed. |
|
Knows issues still to be resolved with the patch:
|
- expanded PR to also fix bpo-20361 and have -b & -bb take precedence over any other warnings options - reverted to the short implicit filter list in Py_DEBUG builds (this is now even shorter than it was previously, as there are *no* implicit filters in debug builds)
ncoghlan
changed the title
-X dev
|
I have made the requested changes; please review again. (The one thing I haven't added yet is more test cases, so I'd appreciate suggestions for those) |
|
Thanks for making the requested changes! @vstinner: please review the changes made to this pull request. |
|
@vstinner Test case added that checks the warnings filter precedence. |
|
@ncoghlan Should the change be added to the documentation in Doc/c-api/init.rst? |
|
Technically yes, but all those docs will be revised for PEP 565, so I plan
to tackle it then.
|
|
Since I cannot modify this PR, I created the PR #4820. Nick told me that he is ok if I modify his PR directly, but I'm not allowed to push into his fork of CPython. I squashed his changes and rebase then on master, I fix most test failures (except of test_semaphore_tracker of test_multiprocessing, but this one is not a regression) when using "PYTHONWARNINGS=error ./python -W error -m test -j0 -r", and I updated -X dev documentation. |
|
I merged my modified version, PR #4820. |
|
Huh, weird - as far as I'm aware, all my PRs have "Allow maintainers to
make modifications" set. Anyway, thanks for getting this change resolved :)
|
Rather than supporting dev mode and the command
line BytesWarning flag directly in the warnings module,
this instead adjusts the initialisation code to add extra
entries to sys.warnoptions when these options are
enabled.
This ensures that dev mode behaves exactly
as if
-Wdefaulthad been passed on thecommand line, including in the way it interacts
with
sys.warnoptions, and with other commandline flags like
-bb.It also ensures that the
-band-bboptionstake precedence of other warnings filter options
like
-WdefaultorPYTHONWARNINGS=ignore.https://bugs.python.org/issue32230
https://bugs.python.org/issue20361