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

[Guido van Rossum]

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/)