[Python-checkins] r45544 - peps/trunk/pep-0343.txt (original) (raw)

phillip.eby python-checkins at python.org
Tue Apr 18 20:55:18 CEST 2006

• Previous message: [Python-checkins] r45543 - in python/trunk: Misc/NEWS Python/pythonrun.c
• Next message: [Python-checkins] buildbot warnings in x86 XP trunk
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Author: phillip.eby Date: Tue Apr 18 20:55:17 2006 New Revision: 45544

Modified: peps/trunk/pep-0343.txt Log: Make "context" vs. "context manager" terminology consistent. Originally, there were only context managers, so a lot of text referred to context managers that now should refer to contexts since the context method was added. All contexts are context managers, so these references were technically correct in some sense, but are easier to understand if the more-specific terms are used.

Modified: peps/trunk/pep-0343.txt

--- peps/trunk/pep-0343.txt (original) +++ peps/trunk/pep-0343.txt Tue Apr 18 20:55:17 2006 @@ -265,8 +265,8 @@ threading.RLock) may provide its own enter() and exit() methods, and simply return 'self' from its context method. On the other hand, an object with more complex state requirements

• (such as decimal.Context) may return a distinct context manager
• object each time its context method is invoked.

• (such as decimal.Context) may return a distinct context object

• each time its context method is invoked.

  If the "as VAR" part of the syntax is omitted, the "VAR =" part of the translation is omitted (but ctx.enter() is still called).

@@ -473,9 +473,9 @@ 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 (this means that all context managers
• are contexts, but not all contexts are context managers).

• "context manager" then encompasses all objects with a context()

• method that returns a context object. (This means that all contexts

• are context managers, but not all context managers are contexts).

  The term "context" is based on the concept that the context object defines a context of execution for the code that forms the body

@@ -529,10 +529,11 @@ on python-dev [4] settled on the term "context manager" for objects which provide enter and exit methods, and "context management protocol" for the protocol itself. With the

•   addition of the __context__ method to the protocol, a natural

•   extension is to call all objects which provide a __context__

•   method "contexts" (or "manageable contexts" in situations where

•   the general term "context" would be ambiguous).

•   addition of the __context__ method to the protocol, the natural

•   adjustment is to call all objects which provide a __context__

•   method "context managers", and the objects with __enter__ and

•   __exit__ methods "contexts" (or "manageable contexts" in

•   situations where the general term "context" would be ambiguous).
    This is now documented in the "Standard Terminology" section.

  1. The originally approved version of this PEP did not include a

@@ -541,9 +542,9 @@ appropriate enter and exit methods for decimal.Context [5]. This approach allows a class to define a native context manager using generator syntax. It also allows a class to use an

•   existing independent context manager as its native context

•   manager by applying the independent context manager to 'self' in

•   its __context__ method. It even allows a class written in C to

•   existing independent context as its native context object by

•   applying the independent context to 'self' in its __context__ 

•   method.  It even allows a class written in C to
    use a generator context manager written in Python.
    The __context__ method parallels the __iter__ method which forms
    part of the iterator protocol.

@@ -558,10 +559,10 @@ 342 [6]. Guido rejected this idea [7]. The following are some of benefits of keeping the enter and exit methods:

•      - it makes it easy to implement a simple context manager in C

•      - it makes it easy to implement a simple context in C
         without having to rely on a separate coroutine builder
       - it makes it easy to provide a low-overhead implementation

•        for context managers which don't need to maintain any

•        for contexts that don't need to maintain any
         special state between the __enter__ and __exit__ methods
         (having to use a generator for these would impose
         unnecessary overhead without any compensating benefit)

• Previous message: [Python-checkins] r45543 - in python/trunk: Misc/NEWS Python/pythonrun.c
• Next message: [Python-checkins] buildbot warnings in x86 XP trunk
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the Python-checkins mailing list