AFAICT, there is no way to filter warnings based on anything but their most immediate caller (please correct me if I'm wrong). This can lead to situations where it's impossible to write a warnings filter that's not brittle. For example: Say I want to filter a certain warnings `sphinx.ext.autodoc` during my build process (e.g. to ignore deprecation warnings when autodoc imports deprecated modules that I need to keep documented). I can filter: ```python warnings.filterwarnings('ignore', category=MatplotlibDeprecationWarning, message=r'(\n|.)*module was deprecated.*') ``` but then when sphinx is then building my gallery of examples, this hides the `DeprecationWarnings` that I do want to see! What I'd like to do is write ```python warnings.filterwarnings('ignore', category=MatplotlibDeprecationWarning, module='sphinx.ext.autodoc', message=r'(\n|.)*module was deprecated.*') ``` however the warning is not actually triggered by the `autodoc` module itself, but instead let's say hypothetically it's triggered by using `imp` internally to load the module. Then I would have to instead do something like the following: ```python warnings.filterwarnings('ignore', category=MatplotlibDeprecationWarning, module='imp', message=r'(\n|.)*module was deprecated.*') ``` but now let's say in the past couple of years, Sphinx, being the well-maintained library that it is, moves to using `importlib.import_module`. Now suddenly warnings are appearing and I have to go edit this guy to fix CI: ```python warnings.filterwarnings('ignore', category=MatplotlibDeprecationWarning, module='importlib', message=r'(\n|.)*module was deprecated.*') ``` This is (at worst) a minor inconvenience in this silly example case, but in general one could imagine that if you want to use an upstream library in your code internally, in a way that raises a warning (that you want to ignore), it's currently impossible to do that without relying on what *should be* implementation details of the library you're using. One obvious solution in my mind is to allow `filterwarnings` to inspect the current stack at the time that a warning is raised, since this contains all of the information needed in principle for the user to decide whether or not to ignore a warning. Has this kind of thing been discussed before? I tried my best to search but couldn't find anything, and while I'm a decades-long *user* of Python I don't tend to keep up with the development side of things.