[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