Repository navigation
-bb option should override -W options #76412
Description
| BPO | 32231 |
|---|---|
| Nosy | @ncoghlan, @vstinner, @serhiy-storchaka |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2019-05-15.02:10:47.867>
created_at = <Date 2017-12-06.10:43:15.337>
labels = ['type-feature', '3.7']
title = '-bb option should override -W options'
updated_at = <Date 2019-05-15.02:10:47.867>
user = 'https://github.com/ncoghlan'bugs.python.org fields:
activity = <Date 2019-05-15.02:10:47.867>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-05-15.02:10:47.867>
closer = 'vstinner'
components = []
creation = <Date 2017-12-06.10:43:15.337>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 32231
keywords = []
message_count = 6.0
messages = ['307717', '307722', '307725', '307726', '307728', '307729']
nosy_count = 3.0
nosy_names = ['ncoghlan', 'vstinner', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '20361'
type = 'enhancement'
url = 'https://bugs.python.org/issue32231'
versions = ['Python 3.7']
Activity
ncoghlan commentedon Dec 6, 2017
When implementing the "-X dev" mode, Victor was asked to make it behave differently from "-Wd", such that "python -bb -X dev" would still raise errors for bytes comparisons.
I don't think making "-X dev" and "-Wd" inconsistent with each other is the right way to address that request. Instead, I think we should find a way to make "-bb" *always* take precedence over any supplied "-W" options.
One way to do that would be to adopt an approach similar to what I've proposed for "-X dev" in https://bugs.python.org/issue32230: instead of making the warnings module aware of the "-bb" setting, we'd instead adjust the initialisation code to inject "error::BytesWarning" into sys.warnoptions *after* all of the entries from environment variables and the command line.
ncoghlan commentedon Dec 6, 2017
(From the discussion at https://bugs.python.org/issue32230#msg307721)
Another benefit we'd gain from this approach is that we could easily omit the filter entirely in the case where neither -b nor -bb is set: in those situations, BytesWarning won't be emitted at all, so we don't really need to define a filter for it.
vstinner commentedon Dec 6, 2017
IMHO the root issue is that there are different options which set warnings filters:
vstinner@apu$ ./python -W default -b -c 'import pprint, sys, warnings; pprint.pprint(warnings.filters); pprint.pprint(sys.warnoptions)'
[('default', None, <class 'Warning'>, None, 0),
('default', None, <class 'BytesWarning'>, None, 0),
('default', None, <class 'ResourceWarning'>, None, 0)]
['default']
Why default::BytesWarning isn't in sys.warnoptions?
I suggest to experiment to create all filters at once in a single list, rather than having sys.warnoptions on one side and init_filters() (Python/_warnings.c) on another side.
It was on my TODO list for the PEP-432 :-) Currently, when Python is embedded, it's not easy to control filters created by init_filters() which can be an issue. I expect a feature like Py_SetPath() to override *all* warnings filters, not only "add" filters on top on existing filters, for the specific case of embedded Python.
ncoghlan commentedon Dec 6, 2017
I'm hesitant to put the *true* default filters in sys.warnoptions, as folks use "bool(sys.warnoptions)" as a check for "Were any warning options set via the environment or the command line?", and we don't want to invalidate that use case.
However, I'm definitely a fan of having the warnings module *only* look at sys.warnoptions, and requiring *all* command line options to route their filter settings through that channel.
https://bugs.python.org/issue32230 adjusts "-X dev" to work that way, and I'm suggesting we do the same here for "-b".
That way, we can fully define the relative ordering of PYTHONWARNINGS, "-X dev", "-W", and "-b" inside pymain_add_warnings_options (and only the true default filters will be appended by the warnings module itself).
ncoghlan commentedon Dec 6, 2017
One potential complication here is that embedding applications would inherit the requirement to do both:
and
to request errors. That's probably OK though, since we're getting into pretty esoteric configuration behaviour at that point.
serhiy-storchaka commentedon Dec 6, 2017
This looks like a duplicate of bpo-20361.