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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com