Context manager and decorator doing much the same as ``warnings.catch_warnings``. However, it also provides a filter mechanism to work around https://bugs.python.org/issue4180. This bug causes Python before 3.4 to not reliably show warnings again after they have been ignor
| 2002 | |
| 2003 | |
| 2004 | class suppress_warnings: |
| 2005 | """ |
| 2006 | Context manager and decorator doing much the same as |
| 2007 | ``warnings.catch_warnings``. |
| 2008 | |
| 2009 | However, it also provides a filter mechanism to work around |
| 2010 | https://bugs.python.org/issue4180. |
| 2011 | |
| 2012 | This bug causes Python before 3.4 to not reliably show warnings again |
| 2013 | after they have been ignored once (even within catch_warnings). It |
| 2014 | means that no "ignore" filter can be used easily, since following |
| 2015 | tests might need to see the warning. Additionally it allows easier |
| 2016 | specificity for testing warnings and can be nested. |
| 2017 | |
| 2018 | Parameters |
| 2019 | ---------- |
| 2020 | forwarding_rule : str, optional |
| 2021 | One of "always", "once", "module", or "location". Analogous to |
| 2022 | the usual warnings module filter mode, it is useful to reduce |
| 2023 | noise mostly on the outmost level. Unsuppressed and unrecorded |
| 2024 | warnings will be forwarded based on this rule. Defaults to "always". |
| 2025 | "location" is equivalent to the warnings "default", match by exact |
| 2026 | location the warning warning originated from. |
| 2027 | |
| 2028 | Notes |
| 2029 | ----- |
| 2030 | Filters added inside the context manager will be discarded again |
| 2031 | when leaving it. Upon entering all filters defined outside a |
| 2032 | context will be applied automatically. |
| 2033 | |
| 2034 | When a recording filter is added, matching warnings are stored in the |
| 2035 | ``log`` attribute as well as in the list returned by ``record``. |
| 2036 | |
| 2037 | If filters are added and the ``module`` keyword is given, the |
| 2038 | warning registry of this module will additionally be cleared when |
| 2039 | applying it, entering the context, or exiting it. This could cause |
| 2040 | warnings to appear a second time after leaving the context if they |
| 2041 | were configured to be printed once (default) and were already |
| 2042 | printed before the context was entered. |
| 2043 | |
| 2044 | Nesting this context manager will work as expected when the |
| 2045 | forwarding rule is "always" (default). Unfiltered and unrecorded |
| 2046 | warnings will be passed out and be matched by the outer level. |
| 2047 | On the outmost level they will be printed (or caught by another |
| 2048 | warnings context). The forwarding rule argument can modify this |
| 2049 | behaviour. |
| 2050 | |
| 2051 | Like ``catch_warnings`` this context manager is not threadsafe. |
| 2052 | |
| 2053 | Examples |
| 2054 | -------- |
| 2055 | |
| 2056 | With a context manager:: |
| 2057 | |
| 2058 | with np.testing.suppress_warnings() as sup: |
| 2059 | sup.filter(DeprecationWarning, "Some text") |
| 2060 | sup.filter(module=np.ma.core) |
| 2061 | log = sup.record(FutureWarning, "Does this occur?") |
no outgoing calls