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

Guido van Rossum guido at python.org
Fri Apr 21 19:54:11 CEST 2006

Phillip, I do recomment you look at decimal.py. If we're not reversing the PEP changes, that module needs to be changed; it has a class Context (that was always there) with a context method which returns an instance of a class ContextManager (newly created for the with-statement). This looks backwards from the PEP's current POV.

--Guido

On 4/21/06, Phillip J. Eby <pje at telecommunity.com> wrote:

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

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list