[Python-Dev] Context management patterns

[Nick Coghlan]

On 19 October 2013 20:47, Glenn Linderman <v+python at g.nevcal.com> wrote:
> Sadly, all the documentation that references "suppressing" an exception, is
> misleading. Misleading enough that you convinced yourself to rename from
> ignore to suppress after reading it, even though the two are nearly
> synonymous.

You misunderstand the two components that formed my rationale for renaming it.

The first part of the rationale is that re-reading all of the current
docs reminded me that this pattern *already* had a consistent name in
the language and library reference (i.e. suppress), and this name was
even mentioned all the way back in PEP 343 (although it wasn't the
primary term there - that honour went to "swallow", which
understandably didn't make it into the reference docs). To avoid
introducing an inconsistency into the documentation for Python 3.4, I
had to choose between rewording all the existing context management
and with statement docs or just using the established name for the new
construct (and I chose the latter path).

The second part of my rationale stems from the fact that ignore and
suppress aren't quite synonyms, and that suppressing something is
*far* more active than ignoring it. If you completely ignore
something, it should be as if it never happened - you certainly don't
take any kind of action in response to it. When you suppress
something, by contrast, there's a clear implication that it still
happens, and then you do something later to make it go away. That
means the potential for confusion changes:

Plausible interpretations of ignore(SomeException):
- that kind of exception is genuinely ignored by never raising it in
the first place and proceeding with the next statement immediately
after the one where it would have been raised
- the exception is raised, but mostly ignored by proceeding with the
next statement in the with statement body
- the exception is raised, but kind of ignored by proceeding with the
next statement after the with statement

Plausible interpretations of suppress(SomeException):
- the exception is raised, but suppressed immediately after the
statement that raised it
- the exception is raised, but suppressed at the end of the with
statement (which is the first change the context manager has to see
it)

With "suppress", the implication that the "exception is raised" part
still happens is *much* stronger, suggesting that the name is not only
more consistent with the existing docs, but also more accurate in an
absolute sense.

Independently of that, one of the things that has become clear to me
in these threads is that many experienced Python developers don't
realise that with statements actually *are* intended to be usable as
control flow constructs (albeit in a quite restrained way, with their
influence on the flow of control being limited solely to the ability
to suppress exceptions). If coming to grips with the behaviour of
contextlib.suppress expands people's horizons beyond merely using them
for resource, state and transaction management, then I see that as a
good thing.

Now, some of the people in that last group are actually *more* likely
to be confused than beginners, since they already have the *mistaken*
impression that with statements don't affect control flow. And if you
have *that* impression, then you're more likely to guess that
suppress() has to be a state management context manager that is giving
the interpreter the instruction to not raise the named exception
types. Discovering that it *doesn't* work that way may then help to
enlighten them as to the true nature of the underlying construct.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia