Repository navigation
warnings.simplefilter and warnings.catch_warnings take tuple[type[Warning], ...] as well as type[Warning] for category parameter #15829
Description
When a warning is encountered by the mechanisms of the warnings module, it uses issubclass checks on its type against the warning filters previously inserted. This makes tuples of warning classes as the category argument to warnings.simplefilter acceptable as well, but the current annotations .
Standard library example of this usage on the main branch, in Lib/codeop.py, under the _maybe_compile helper function:
# Disable compiler warnings when checking for incomplete input.
with warnings.catch_warnings():
warnings.simplefilter("ignore", (SyntaxWarning, DeprecationWarning))
try:
compiler(source, filename, symbol, flags=flags)
except SyntaxError: # Let other compile() errors propagate.
try:
compiler(source + "\n", filename, symbol, flags=flags)
return None
except _IncompleteInputError:
return None
except SyntaxError:
pass
# fallthroughThe analogous parameter in the warnings.catch_warnings constructor, introduced in Python 3.11 and added to typeshed by #7685, is passed straight through to warnings.simplefilter. Its type should be updated accordingly.
Activity
jonathandung commentedon May 24, 2026
Forgot to mention
warnings.filterwarnings, which is similar, and the undocumentedfilterssymbol at the top level.jonathandung commentedon May 24, 2026
After reading through the source code, it appears as though
filterwarningsexplicitly checks that thecategoryis a subclass ofWarning, and not a tuple of. This is a weird inconsistency.