I propose the following expansion of the interface of contextlib.suppress. Currently, when entering the context, suppress returns None. Instead, it could return an object that provides some detail about the exception.

Inspiration for an implementation exists in pytest (https://github.com/pytest-dev/pytest/blob/ff3d13ed0efab6692a07059b1d61c53eec6e0412/_pytest/python_api.py#L627), capturing the commonly-encountered use-cases, where one wishes to capture, suppress, and then act on a subset of exceptions, allowing others to raise normally.

In [py-181](https://github.com/pytest-dev/py/pull/181), I suggest exposing this functionality generally, but others had an instinct similar to mine - that perhaps the stdlib should be providing this interface.

In addition to saving the exception for inspection, the pytest implementation also allows a "message" to be supplied (for those exceptions where only some subset of the class of Exception is suppressed).

I present this concept here for consideration and feedback. Can contextlib.suppress be expanded with such an interface?

What kind useful information to you expect to get before an exception is raised?

For example:

    with suppress(FileNotFoundError) as e:
         os.remove(somefile)

What could *e* possibly be that would be useful.  AFAICT, all we know at the time of __enter__ is the exception class.  No new information was created by the context manager call.

Ideally, it would be great is this API were to remain simple.  User code would likely be more clear if any other logic were done outside the context manager rather than happening indirectly and inexplicitly in the suppress call.  To me, "suppress" means suppress -- it doesn't mean capture and analyze that which is ignored.  So, at first glance, this seems like a mix of feature creep and mission creep.

I'm not sure that contextlib.suppress() should be added at first place.

    try:
        os.remove(somefile)
    except FileNotFoundError:
        pass

is a tiny bit longer, but is more explicit, doesn't depend on the other module, works in all Python versions that have this exception, and is easily extensible.

    try:
        os.remove(somefile)
    except FileNotFoundError as e:
        # what do you want to do with e?
        pass

I wouldn't expand the scope of contextlib.suppress, since it has a pretty clear purpose: pretend the exception never happened. (This was even clearer with the original "ignored" name, before I was talked into changing it to use the current more technically correct, but far less intuitive, name - a decision I still regret).

However, when writing tests, or otherwise introspecting thrown exceptions (i.e. in programs about programs), it's not uncommon for me to want a construct like:

    with catch(FileNotFoundError) as err:
        os.remove(somefile)

    if err.caught is not None:
        ...

The benefit over the try/catch form is similar to the benefits of suppress:

1. Up front declaration that that kind of exception isn't going to escape and execution will continue after the suite
2. More efficient use of vertical whitespace (one extra line instead of three)

In this case, we could also end up expanding the API to provide a better building block for testing tools like "assertRaises" and "assertRaisesRegex" by accepting a "filter" callback argument that receives the caught exception, and can either return False to suppress it, True to reraise it, or explicitly raise a different exception to replace it. (That suggested callback API is deliberately similar to an __exit__ implementation that only accepts the exception value, rather than the full type/value/traceback triple).

(The simpler name may mean that folks end up preferring catch() to suppress() even when they don't need the result of __enter__. I'd be OK with that outcome).