[Python-checkins] r45544 - peps/trunk/pep-0343.txt

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


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.
 
     4. 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)


More information about the Python-checkins mailing list