New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-bb option should override -W options #76412
Comments
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. |
(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. |
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)' 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. |
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). |
One potential complication here is that embedding applications would inherit the requirement to do both: Py_BytesWarningFlag = 2; and PySys_AddWarnOption(L"error::BytesWarning"); to request errors. That's probably OK though, since we're getting into pretty esoteric configuration behaviour at that point. |
This looks like a duplicate of bpo-20361. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: