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 <[EMAIL PROTECTED]> 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@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/) _______________________________________________ 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
