The PEP 343 implementation for the beta releases seems to have met with general approval (PEP 0 has actually been showing 343 as being Final for ages)
This commit is contained in:
parent
36b6caf8da
commit
12bfa7c87f
43
pep-0343.txt
43
pep-0343.txt
|
@ -3,11 +3,11 @@ Title: The "with" Statement
|
|||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: Guido van Rossum, Nick Coghlan
|
||||
Status: Accepted
|
||||
Status: Final
|
||||
Type: Standards Track
|
||||
Content-Type: text/plain
|
||||
Created: 13-May-2005
|
||||
Post-History: 2-Jun-2005, 16-Oct-2005, 29-Oct-2005, 23-Apr-2006, 1-May-2006
|
||||
Post-History: 2-Jun-2005, 16-Oct-2005, 29-Oct-2005, 23-Apr-2006, 1-May-2006, 30-Jul-2006
|
||||
|
||||
Abstract
|
||||
|
||||
|
@ -27,16 +27,11 @@ Author's Note
|
|||
|
||||
Python's alpha release cycle revealed terminology problems in this
|
||||
PEP and in the associated documentation and implementation [14].
|
||||
So while the PEP is already accepted in principle, it won't really
|
||||
be considered stable until the status becomes Final.
|
||||
|
||||
The current version of the PEP reflects the discussions that
|
||||
occurred on python-dev shortly after the release of Python 2.5a2.
|
||||
The PEP will continue to be updated to reflect any changes made to
|
||||
the details of the feature prior to the final Python 2.5 release.
|
||||
The PEP stabilised around the time of the first Python 2.5 beta
|
||||
release.
|
||||
|
||||
Yes, the verb tense is messed up in a few places. We've been
|
||||
working on this PEP for nearly a year now, so things that were
|
||||
working on this PEP for over a year now, so things that were
|
||||
originally in the future are now in the past :)
|
||||
|
||||
Introduction
|
||||
|
@ -481,7 +476,7 @@ Standard Terminology
|
|||
terms would otherwise be unclear.
|
||||
|
||||
Given the existence of objects such as the decimal module's
|
||||
arithmetic context, a term "context" is unfortunately ambiguous.
|
||||
arithmetic context, the term "context" is unfortunately ambiguous.
|
||||
If necessary, it can be made more specific by using the terms
|
||||
"context manager" for the concrete object created by the context
|
||||
expression and "runtime context" or (preferably) "runtime
|
||||
|
@ -519,24 +514,6 @@ Caching Context Managers
|
|||
affected context manager should make that clear.
|
||||
|
||||
|
||||
Open Issues
|
||||
|
||||
1. Greg Ewing raised the question of whether or not the term
|
||||
"context manager" was too generic and suggested "context guard"
|
||||
as an alternative name. [16]
|
||||
|
||||
2. In Python 2.5a2, the decorator in contextlib to create a
|
||||
context manager from a generator function is called
|
||||
@contextfactory. This made sense when the __context__()
|
||||
method existed and the result of the factory function was
|
||||
a managed context object.
|
||||
With the elimination of the __context__() method, the
|
||||
result of the factory function is once again a context
|
||||
manager, suggesting the decorator should be renamed to
|
||||
either @contextmanager or @managerfactory.
|
||||
The PEP currently uses @contextmanager.
|
||||
|
||||
|
||||
Resolved Issues
|
||||
|
||||
The following issues were resolved by BDFL approval (and a lack
|
||||
|
@ -563,6 +540,14 @@ Resolved Issues
|
|||
TypeError rather than AttributeError is an accident of history,
|
||||
rather than a deliberate design decision [11].
|
||||
|
||||
3. Objects with __enter__/__exit__ methods are called "context
|
||||
managers" and the decorator to convert a generator function
|
||||
into a context manager factory is ``contextlib.contextmanager``.
|
||||
There were some other suggestions [16] during the 2.5 release
|
||||
cycle but no compelling arguments for switching away from the
|
||||
terms that had been used in the PEP implementation were made.
|
||||
|
||||
|
||||
Rejected Options
|
||||
|
||||
For several months, the PEP prohibited suppression of exceptions
|
||||
|
|
Loading…
Reference in New Issue