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

Terry Reedy tjreedy at udel.edu
Sun Apr 23 01:41:00 CEST 2006


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:444A20D9.5010607 at gmail.com...
> As Phillip pointed out, we need input from people that haven't been 
> intimately
> involved in the PEP 343 discussions

OK, here is my attempt to cut the knot.

To me, 'context' and 'context manager' can be seen as near synonyms; either 
could be used to describe the thing that 'governs' the block execution.  I 
(and some other others) prefer the shorter term; yet I can see how someone 
(you, at least) could prefer the longer, more explicit term.

To me, the thing after 'with' that makes the whatever for the block is 
DEFINITELY not a 'context'; trying to twist context to mean that is a brain 
twister.  Calling it 'context manager' is possible if one interpretes 
'manager' instead as a hands-off manager who appoints a foreman to do the 
actual work and then departs.  But the term is ambiguous as this discussion 
has shown.

So I propose that the context maker be called just that: 'context maker'. 
That should pretty clearly not be the context that manages the block 
execution.

An additional source of confusion is that we can name a function got 
several reasons; among them one is what it is, another is what it returns. 
For instance, a generic generator for-loop could be written as either of
  for item in generator_function(): <body>
  for item in generator(): <body>
In context, I think the second reads better, as long as it is clear that 
the function name 'generator' refers what it returns and not what it is.

Similar, a context_maker function could be named any of 'context_maker', 
'context_manager', or 'context', with the latter two referring to the 
return value.  In the context of 'with ____ as name:', either of the latter 
two reads better to me.

I would call the decorator @contextmaker since that is what it turns the 
decorated function into.

Well, I hope this slightly different viewpoint is at least a bit helpful.

Terry Jan Reedy






More information about the Python-Dev mailing list