Walker Hale IV added the comment:

Clarifying the documentation regarding the __enter__ method eliminates the need 
for further discussion on this point regarding pop_all(), which was really just 
the motivating use case.

That leaves the question of the most readable documentation change that 
accomplishes the result — some point between verbose and terse that minimizes 
the time required to comprehend the material.

My problem with the language "ExitStack instances return themselves when used 
in a with statement" is that it only specifies the return value of the 
__enter__ method but leaves open the question of whether the __enter__ method 
is doing anything else, particularly in the case of an ExitStack that is 
already loaded with context managers. How does a reader know that the __enter__ 
method of a loaded ExitStack doesn't call the __enter__ method of the the 
context managers inside? The documentation elsewhere provides strong evidence 
against this, but nothing that makes the point explicit. The reader is left 
with an exercise in deduction.

How about replacing my previous wording with: "The __enter__ method has no 
behavior besides returning the ExitStack instance?"

(I feel a little dirty using that language, since it might tie the hands of 
future developers. The truly correct wording would be "The __enter__ method is 
idempotent and behaves as if the only thing it does is return the ExitStack 
instance." That more verbose description gives future developers the freedom to 
do weird JIT optimizations and caching as needed, but who has the patience for 
such legally exhaustive specification?)

Placing the wording where I did — at the end of the class discussion and prior 
to the new methods — prevents this point from obscuring the main purpose of 
ExitStack while still leaving a place for such messy but important details. 
(Amazing the thought that goes into documenting a two-line method.)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28516>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to