[Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
>On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
> > fit the new definition. So we settled on calling them "context managers"
> > instead.
>  ...
> > method. Instead, the new term "manageable context" (or simply "context")
> > was introduced to mean "anything with a __context__ method". This was OK,
>
>Meaning that 'manageable context' objects create and destroy 'context
>managers'...  My view is still that 'context manager' is a terrible
>name when used alongside objects called 'contexts': the object doesn't
>manage anything, and it certainly doesn't manage contexts -- in fact
>it's created by 'context' objects.

And that's more or less why I wrote the documentation the way I did.

Nick, as I understand your argument, it's that we were previously using the 
term "context manager" to mean "thing with __enter__ and __exit__".  But 
that was *never* my interpretation.

My understanding of "context manager" was always, "thing that you give to a 
with statement".

So to me, when we added a __context__ method, we were creating a *new 
object* that hadn't existed before, and we moved some methods on to 
it.  Thus, "context manager" still meant "thing you give to the with 
statement" -- and that never changed, from my POV.

And that's why I see the argument that we've "reversed" the terminology as 
bogus: to me it's been consistent all along.  We just added another object 
*besides* the context manager.

Note too that the user of the "with" statement doesn't know that this other 
object exists, and in fact sometimes it doesn't actually exist, it's the 
same object.  None of this is relevant for the with-statement user, only 
the context manager.  So there's no reason (IMO) to monkey with the 
definition of "context manager" as "thing you use in a with statement".

Now, I get your point about @contextmanager on a __context__ method, and I 
agree that that seems backwards at first.  What I don't see is how to 
change the terminology to handle that subtlety in a way that doesn't muck 
up the basically simple definitions that are in place now.

If it must be explained, however, I'd rather simply document it in 
contextlib that @contextmanager-decorated functions return an object that 
is both a context manager and a context (or whatever name you want for the 
invisible-behind-the-scenes-thing with enter and exit methods).  Since it 
is possible for an object to be both, that seems to do fine for explaining 
why you can use @contextmanager to define a __context__ method.

I'm definitely open to other terminology for the invisible thing besides 
"context", but I don't care for "managed context" or "manageable context", 
as these aren't much better.  I'm somewhat tempted by "context instance" or 
"context invocation".  E.g, the __context__ method should return a "context 
instance": an object representing a single instance of use of the 
context.  There's a wee hint of suggestion that this means "instance of 
type context", but it's more suggestive of one-time use than "context object".