mirror of
https://github.com/python/cpython.git
synced 2025-08-03 08:34:29 +00:00
Get rid of a couple more context object references, fix some markup and clarify what happens when a generator context function swallows an exception.
This commit is contained in:
parent
afd5e63e24
commit
d8accb32a5
2 changed files with 10 additions and 9 deletions
|
@ -13,7 +13,7 @@ Functions provided:
|
|||
|
||||
\begin{funcdesc}{contextmanager}{func}
|
||||
This function is a decorator that can be used to define a factory
|
||||
function for \keyword{with} statement context objects, without
|
||||
function for \keyword{with} statement context managers, without
|
||||
needing to create a class or separate \method{__enter__()} and
|
||||
\method{__exit__()} methods.
|
||||
|
||||
|
@ -52,9 +52,10 @@ occurred. Thus, you can use a
|
|||
the error (if any), or ensure that some cleanup takes place. If an
|
||||
exception is trapped merely in order to log it or to perform some
|
||||
action (rather than to suppress it entirely), the generator must
|
||||
reraise that exception. Otherwise the \keyword{with} statement will
|
||||
treat the exception as having been handled, and resume execution with
|
||||
the statement immediately following the \keyword{with} statement.
|
||||
reraise that exception. Otherwise the generator context manager will
|
||||
indicate to the \keyword{with} statement that the exception has been
|
||||
handled, and execution will resume with the statement immediately
|
||||
following the \keyword{with} statement.
|
||||
\end{funcdesc}
|
||||
|
||||
\begin{funcdesc}{nested}{mgr1\optional{, mgr2\optional{, ...}}}
|
||||
|
@ -81,9 +82,9 @@ with A as X:
|
|||
Note that if the \method{__exit__()} method of one of the nested
|
||||
context managers indicates an exception should be suppressed, no
|
||||
exception information will be passed to any remaining outer context
|
||||
objects. Similarly, if the \method{__exit__()} method of one of the
|
||||
nested context managers raises an exception, any previous exception
|
||||
state will be lost; the new exception will be passed to the
|
||||
managers. Similarly, if the \method{__exit__()} method of one of the
|
||||
nested managers raises an exception, any previous exception state will
|
||||
be lost; the new exception will be passed to the
|
||||
\method{__exit__()} methods of any remaining outer context managers.
|
||||
In general, \method{__exit__()} methods should avoid raising
|
||||
exceptions, and in particular they should not re-raise a
|
||||
|
|
|
@ -1778,8 +1778,8 @@ define a runtime context:
|
|||
|
||||
An example of a context manager that returns itself is a file object.
|
||||
File objects return themselves from __enter__() to allow
|
||||
\function{open()} to be used as the context expression in a with
|
||||
statement.
|
||||
\function{open()} to be used as the context expression in a
|
||||
\keyword{with} statement.
|
||||
|
||||
An example of a context manager that returns a related
|
||||
object is the one returned by \code{decimal.Context.get_manager()}.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue