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

Phillip J. Eby pje at telecommunity.com
Sat Apr 22 08:19:03 CEST 2006


At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
>Phillip J. Eby 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".
>
>Then why didn't you speak up when the discussion was summarised in PEP 343 
>for Guido's approval? I said it explicitly:
>
>      This PEP proposes that the protocol used by the with statement be
>      known as the "context management protocol", and that objects that
>      implement that protocol be known as "context managers". The term
>      "context" then encompasses all objects with a __context__() method
>      that returns a context manager object. (This means that all context
>      managers are contexts, but not all contexts are context managers)
>
>I guess a slight ambiguity came in from the fact I didn't spell out that 
>the protocol I was referring to was all three methods with __context__ 
>returning self (i.e. the moral equivalent of the 'iterator protocol'). But 
>the rest of the paragraph doesn't make any sense otherwise.

Because the last time I looked at the PEP, I was trying to make sure that 
the code samples in the PEP worked with Guido's last-minute decision to go 
with the return vs. raise protocol that I originally proposed for __exit__, 
and didn't have the time to sort through the terminology change.

Later, when I wrote up documentation, I mostly did it from memory.  The 
next time I looked at the PEP was when AMK asked for clarification.


>That may have been what you personally thought, but it's not what the PEP 
>said. If you disagreed with the summarisation in the PEP, you should have 
>said so before Guido approved it, or brought it back to python-dev as a 
>discussion about changing the standard terminology rather than just "the 
>PEP's confusing, I want to clear it up" (and completely changing the 
>meaning in the process).

I changed the PEP because Guido asked me to, right here on Python-Dev, 
after AMK asked the question and I seconded his guess as to the 
interpretation.  I wouldn't have otherwise checked in changes to a PEP that 
doesn't have my name on it:

http://mail.python.org/pipermail/python-dev/2006-April/063856.html

If you have a problem with what I did to the PEP, kindly take it up with 
Guido.  If you have a problem with the documentation I took the time to 
write and contribute, by all means change it.  At this point, I'm getting 
pretty tired of people of accusing me of violating procedures around here, 
and I'm past caring what you do or don't call the bloody objects.  At least 
I've gotten contextlib and test_contextlib to actually work, and arranged 
for there to be *some* documentation for the "with" statement and the 
contextlib module.

Meanwhile, the iterator-iterable analogy is false.  You have to be able to 
iterate over an iterator, but as AMK pointed out, you don't have to be able 
to pass a [thing having __enter__/__exit__] to a "with" statement.  So I 
was wrong to apply that analogy myself, as are you now.

That having been said, I don't think either you or I or even Guido should 
be the ones to fix the PEP and the docs at this point, as we've all stared 
at the bloody thing way too long to see it with fresh eyes.  So far, AMK is 
the one who's finding all our screwups, so maybe he should be the one to 
explain it all to *us*.  :)



More information about the Python-Dev mailing list