[Python-Dev] Why are contexts also managers? (was r45544 (original) (raw)

[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