[Python-Dev] Why are contexts also managers? (was r45544 (original) (raw)

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

Phillip J. Eby pje at telecommunity.com
Fri Apr 21 19:01:09 CEST 2006

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".

More information about the Python-Dev mailing list