Context manager to ensure no warnings are issued

Follow up to https://github.com/pytest-dev/pytest/issues/9386, starting this thread to discuss how to support the use case of “inside the given with block, no warning should be generated”.

Seems most users assumed this idiom:

with pytest.warns(None):
    ...

Would ensure that the code inside the with block would not issue any warning, raising an error if it did.

However that was never the case, and pytest.warns(None) would do nothing (warning or no warning generated). To warn users about this common mistake, we added a deprecation warning when None was passed to pytest.warns (https://github.com/pytest-dev/pytest/pull/8677).

When 7.0.0rc1 was released, some issues were reported about this: https://github.com/pytest-dev/pytest/issues/9402, #9386.

Users would like a way to ensure a block of code does not raise any warning, something which we never really supported.

Our current suggestion is to use warnings.catch_warnings(), followed by simplefilter("error"):

with warnings.catch_warnings():
    warnings.simplefilter("error")
    ...

However as mentioned in https://github.com/pytest-dev/pytest/issues/9402, this does not apply directly if you have a dynamic check:

warn_typ = FutureWarning if input == "nc" else None
with pytest.warns(warn_typ):
    ...

So far we have the following proposals:

1. Keep things as is, improving the docs and suggesting catch_warnings (https://github.com/pytest-dev/pytest/issues/9002).
2. Introduce a new context manager, pytest.does_not_warn() (https://github.com/pytest-dev/pytest/issues/9386#issuecomment-988800080).
3. Change pytest.warns(None) to mean that no warning should be raised (https://github.com/pytest-dev/pytest/issues/9402#issuecomment-990777522).

I think this is worth reaching a consensus before the 7.0.0 release is out.

[olgarithms]

Happy to take this!

[olgarithms]

Since this is sparking some debate, I agree it is preferable to delay the API. I am going to add more detail in the deprecation message as suggested then instead!