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:
Nick Coghlan 2006-07-30 12:19:23 +00:00
parent 36b6caf8da
commit 12bfa7c87f
1 changed files with 14 additions and 29 deletions

View File

@ -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