2. Looking it up is hard. If I Google "python ignore warnings" the top result is a Stack Overflow question where neither the accepted answer nor the most upvoted answer mention specifying a module. The second Google result is the Python docs which are not easy to read through.
Hmm, I think we may benefit from focusing the efforts on this point (at least at first), particularly with regards to making the official documentation for the warnings module [1] easier to understand with some more examples, or perhaps writing a warnings HOWTO guide [2], which could include the correct way to add filters for specific warning types by module for a significant number of different filters. From my perspective, this seems to be more of an issue with a lack of understanding and clear guides for using the existing tools, rather than a direct indication that additional tools need to be added.
3. There's lots of similarly named methods and it's hard to find the right one. Is it catch_warnings, simplefilter, or filterwarnings?
While I agree that the names might be a bit similar, I personally find that the names accurately describe what each of them do, particularly `filterwarnings()` and `catch_warnings()`. The purpose of `simplefilter()` in relation to `filterwarnings()` might not be as obvious without reading the documentation, but I don't think there's much that can reasonably be done to address it. I also don't find it to be an especially significant concern.
4. When warnings are displayed, they show the filename, but filters require a module name, and converting between the two is tedious.
I could see it being useful to have a utility for filtering warnings by filename rather than just module, if it's reasonably possible to implement.
5. The more warnings there are, and thus the more serious the need to filter them properly, the more work it is to write all the filters.
This could be potentially addressed by adding an example in the warning docs or a new warnings HOWTO that includes something along the lines of the following: ``` modules_to_filter = {"foo": ResourceWarning, "bar": DeprecationWarning} for mod, cat in modules_to_filter.items(): warnings.filterwarnings("ignore", category=cat, module=mod) ``` (I suspect the actual documented example would be much more fleshed out and explained, the above was very quickly thrown together as a rough example) Alternatively, we could consider adding a helper function to the warnings module for adding a filter with the same action and warning category across multiple modules at once; by accepting a collection of a strings instead of a single string (like `filterwarnings()` does for it's *module* parameter). I'm not certain if the implementation would be too trivial to justify a new helper function for it, but the use case may be common enough for something like that to be reasonable.
I propose we add a built in mechanism that is easy to use and remember which displays Python code that can be copy pasted.
I really don't like the idea of a builtin that specifically revolves around the expectation of its output being copied and pasted as code elsewhere, particularly from an API design perspective. Also, *if* we were to consider something like this, it seems more appropriate to be included in the warnings module rather than as a builtin.
Does this seem like a good general idea?
-1 on the addition of the proposed builtin, but +1 on the general idea of
making the process of correctly adding a decent volume of warning filters
more clear.
---
[1] - https://docs.python.org/3/library/warnings.html
[2] - https://docs.python.org/3/howto/index.html
On Tue, Feb 25, 2020 at 4:04 PM Alex Hall
This is inspired by the [discussion on iterable strings]( https://mail.python.org/archives/list/python-ideas@python.org/thread/WKEFHT4...), although I think it has applications elsewhere.
Sometimes programs emit warnings that need to be filtered out. Maybe they're coming from dependencies that we don't control, or maybe it's our own code but it's a problem that can't be fixed or isn't worth the trouble.
But filtering warnings correctly isn't very easy. You generally shouldn't ignore all warnings, as this would hide important ones. Similarly, you probably shouldn't even filter an entire category, which is what many end up doing. A good compromise is to specify both the category and the module. In particular this lets you ignore warnings from libraries while still being able to see warnings from your own code. But there are obstacles on the way:
1. Remembering the syntax is hard. I've never been able to. 2. Looking it up is hard. If I Google "python ignore warnings" the top result is a Stack Overflow question where neither the accepted answer nor the most upvoted answer mention specifying a module. The second Google result is the Python docs which are not easy to read through. 3. There's lots of similarly named methods and it's hard to find the right one. Is it catch_warnings, simplefilter, or filterwarnings? 4. When warnings are displayed, they show the filename, but filters require a module name, and converting between the two is tedious. 5. The more warnings there are, and thus the more serious the need to filter them properly, the more work it is to write all the filters.
I propose we add a built in mechanism that is easy to use and remember which displays Python code that can be copy pasted. For example, this could be a configuration option which causes the line of code to be shown in stderr immediately after the actual warning. Alternatively, here's a context manager / decorator which prints the code after it exits:
import inspect import warnings from contextlib import contextmanager import __main__
@contextmanager def showfilters(): with warnings.catch_warnings(record=True) as warnings_list: yield
for warning in warnings_list: if warning.filename == getattr(__main__, "__file__", object()): module = "__main__" else: module = inspect.getmodulename(warning.filename) module = bool(module) * f", module={module!r}" print( f"warnings.filterwarnings('ignore', " f"category={warning.category.__name__}" f"{module})" )
# Sample usage # Prints the below, uncomment to confirm that output disappears # warnings.filterwarnings('ignore', category=UserWarning, module='__main__') # warnings.filterwarnings('ignore', category=SyntaxWarning)
@showfilters() # comment out to see original warnings def main(): warnings.warn("DOOM") exec("assert (1, 2)")
main()
This is of course a rough implementation, there are probably things it does wrong and there's all sorts of details about the desired behaviour we could debate about. The aim is that the code it prints is good enough for most cases and can easily be edited, particularly by deleting lines. Does this seem like a good general idea? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YGI6EJ... Code of Conduct: http://python.org/psf/codeofconduct/