[Python-Dev] More on contextlib - adding back a contextmanager decorator

[Greg Ewing]

Guido van Rossum wrote:

> I believe the context API design has gotten totally out of hand.

My thoughts exactly!

> I have a counter-proposal: let's drop __context__... would it
> really be such a big deal to let the user make an explicit call to
> some appropriately named method?

Another possibility I thought of, for the case where
an object is needed to keep track of the state of each
invocation of a context, is to have the __enter__ method
return the state object, which the with-statement tucks
away and later passes to the __exit__ method.

Also a thought on terminology. Even though it seems I
may have been the person who thought it up originally,
I'm not sure I like the term "manager". It seems rather
wooly, and it's not clear whether a "context manager"
is supposed to manage just one context or multiple
contexts.

I've been thinking about the terms "guarded context"
and "context guard". We could say that the with-statement
executes its body in a guarded context (an abstract
notion, not a concrete object). To do this, it creates
a context guard (a concrete object) with __enter__
and __exit__ methods that set up and tear down the
guarded context. This seems clearer to me, since I
can more readily visualise a "guard" object being
specially commissioned to deal with one particular
job (guarding a particular invocation of a context).

With only one object, there wouldn't be a need for any more
terms. But if another term is needed for an object with a
__context__ method or equivalent, I rather liked Nick's
"context specifier".

--
Greg