editorial tweaks

pep-0311.txt

@@ -1,16 +1,20 @@
 PEP: 311
-Title: Simplified Global Interpreter Lock acquisition for extensions
+Title: Simplified Global Interpreter Lock Acquisition for Extensions
 Version: $Revision$
 Last-Modified: $Date$
 Author: Mark Hammond <mhammond@skippinet.com.au>
 Status: Draft
-Type: 
+Type: Standards Track
 Content-Type: text/plain
 Created: 05-Feb-2003
 Post-History: 05-Feb-2003 14-Feb-2003
 
+
 Open Issues
-    This is where I note comments from people that are yet to be resolved.
+
+    This is where I note comments from people that are yet to be
+    resolved.
+
     - JustvR prefers a PyGIL prefix over PyAutoThreadState.
     - JackJ notes that the "Auto" prefix will look a little silly
       in a few years, assuming this becomes the standard way of
@@ -25,6 +29,7 @@ Open Issues
     - Should we provide Py_AUTO_THREAD_STATE macros?
     - Is my "Limitation" regarding PyEval_InitThreads() OK?
 
+
 Abstract
 
     This PEP proposes a simplified API for access to the Global
@@ -38,6 +43,7 @@ Abstract
     strategy is proposed, along with an initial, platform independent
     implementation.
 
+
 Rationale
 
     The current Python interpreter state API is suitable for simple,
@@ -96,6 +102,7 @@ Rationale
     provide error-free, complex extension modules that take full
     advantage of Python's threading mechanisms.
 
+
 Limitations and Exclusions
 
     This proposal identifies a solution for extension authors with
@@ -108,15 +115,15 @@ Limitations and Exclusions
 
     This API will not perform automatic initialization of Python, or
     initialize Python for multi-threaded operation.  Extension authors
-    must continue to call Py_Initialize(), and for multi-threaded 
+    must continue to call Py_Initialize(), and for multi-threaded
     applications, PyEval_InitThreads().  The reason for this is that
     the first thread to call PyEval_InitThreads() is nominated as the
     "main thread" by Python, and so forcing the extension author to
-    specifiy the main thread (by forcing her to make this first call)
+    specify the main thread (by forcing her to make this first call)
     removes ambiguity.  As Py_Initialize() must be called before
-    PyEval_InitThreads(), and as both of these functions currently support
+    PyEval_InitThreads(), and as both of these functions currently
-    being called multiple times, the burden this places on extension
+    support being called multiple times, the burden this places on
-    authors is considered reasonable.
+    extension authors is considered reasonable.
 
     It is intended that this API be all that is necessary to acquire
     the Python GIL.  Apart from the existing, standard
@@ -125,6 +132,7 @@ Limitations and Exclusions
     by the extension.  Extensions with such complicated requirements
     are free to continue to use the existing thread state API.
 
+
 Proposal
 
     This proposal recommends a new API be added to Python to simplify
@@ -169,7 +177,7 @@ Proposal
     corresponding PyAutoThreadState_Ensure call (but generally this
     state will be unknown to the caller, hence the use of the
     AutoThreadState API.)
-    
+
     Every call to PyAutoThreadState_Ensure must be matched by a
     call to PyAutoThreadState_Release on the same thread.
     */
@@ -187,19 +195,22 @@ Proposal
         PyAutoThreadState_Release(state);
     }
 
+
 Design and Implementation
 
     The general operation of PyAutoThreadState_Ensure() will be:
+
     - assert Python is initialized.
-    - Get a PyThreadState for the current thread, creating and saving if 
+    - Get a PyThreadState for the current thread, creating and saving
-      necessary.
+      if necessary.
     - remember the current state of the lock (owned/not owned)
     - If the current state does not own the GIL, acquire it.
-    - Increment a counter for how many calls to PyAutoThreadState_Ensure
+    - Increment a counter for how many calls to
-      have been made on the current thread.
+      PyAutoThreadState_Ensure have been made on the current thread.
     - return
 
     The general operation of PyAutoThreadState_Release() will be:
+
     - assert our thread currently holds the lock.
     - If old state indicates lock as previously unlocked, release GIL.
     - Decrement the PyAutoThreadState_Ensure counter for the thread.
@@ -219,14 +230,18 @@ Design and Implementation
     a way that platforms can provide a more optimal implementation if
     desired.
 
+
 Implementation
-    An implementation of this proposal can be found at 
+
+    An implementation of this proposal can be found at
     http://www.python.org/sf/684256
 
+
 References
 
     [1] http://mail.python.org/pipermail/python-dev/2002-December/031424.html
 
+
 Copyright
 
     This document has been placed in the public domain.

pep-0312.txt

@@ -10,19 +10,23 @@ Created: 11-Feb-2003
 Python-Version: 2.4
 Post-History:
 
+
 Abstract
 
     This PEP proposes to make argumentless lambda keyword optional in
     some cases where it is not grammatically ambiguous.
 
+
 Motivation
 
     Lambdas are useful for defining anonymous functions, e.g. for use
     as callbacks or (pseudo)-lazy evaluation schemes.  Often, lambdas
-    are not used when they would be appropriate, just because the keyword
+    are not used when they would be appropriate, just because the
-    "lambda" makes code look complex.  Omitting lambda in some special
+    keyword "lambda" makes code look complex.  Omitting lambda in some
-    cases is possible, with small and backwards compatible changes to
+    special cases is possible, with small and backwards compatible
-    the grammar, and provides a cheap cure against such "lambdaphobia".
+    changes to the grammar, and provides a cheap cure against such
+    "lambdaphobia".
+
 
 Rationale
 
@@ -31,24 +35,28 @@ Rationale
     argumentless lambdas easier, by omitting the "lambda" keyword.
     itself.  Implementation can be done simply changing grammar so it
     lets the "lambda" keyword be implied in a few well-known cases.
-    In particular, adding surrounding brackets lets you specify nullary
+    In particular, adding surrounding brackets lets you specify
-    lambda anywhere.
+    nullary lambda anywhere.
+
 
 Syntax
 
-    An argumentless "lambda" keyword can be omitted in the following cases:
+    An argumentless "lambda" keyword can be omitted in the following
+    cases:
 
-      * immediately after "=" in named parameter assignment or default value
+      * immediately after "=" in named parameter assignment or default
-        assignment;
+        value assignment;
 
       * immediately after "(" in any expression;
 
       * immediately after a "," in a function argument list;
 
-      * immediately after a ":" in a dictionary literal;  (not implemented)
+      * immediately after a ":" in a dictionary literal; (not
+        implemented)
 
       * in an assignment statement; (not implemented)
 
+
 Examples of Use
 
     1) Inline "if":
@@ -79,13 +87,15 @@ Examples of Use
 
         with(mylock, :x(y(), 23, z(), 'foo'))
 
+
 Implementation
 
     Implementation requires some tweaking of the Grammar/Grammar file
-    in the Python sources, and some adjustment of Modules/parsermodule.c
+    in the Python sources, and some adjustment of
-    to make syntactic and pragmatic changes.
+    Modules/parsermodule.c to make syntactic and pragmatic changes.
 
-    (Some grammar/parser guru is needed to make a full implementation.)
+    (Some grammar/parser guru is needed to make a full
+    implementation.)
 
     Here are the changes needed to Grammar to allow implicit lambda:
 
@@ -95,22 +105,24 @@ Implementation
 
         imptest: test | implambdef
 
-        atom: '(' [imptestlist] ')' | '[' [listmaker] ']' | 
+        atom: '(' [imptestlist] ')' | '[' [listmaker] ']' |
         '{' [dictmaker] '}' | '`' testlist1 '`' | NAME | NUMBER | STRING+
 
         implambdef: ':' test
-    
+
         imptestlist: imptest (',' imptest)* [',']
 
         argument: [test '='] imptest
 
-    Three new non-terminals are needed: imptest for the place where implicit 
+    Three new non-terminals are needed: imptest for the place where
-    lambda may occur, implambdef for the implicit lambda definition itself, 
+    implicit lambda may occur, implambdef for the implicit lambda
-    imptestlist for a place where imptest's may occur.   
+    definition itself, imptestlist for a place where imptest's may
+    occur.
+
+    This implementation is not complete. First, because some files in
+    Parser module need to be updated. Second, some additional places
+    aren't implemented, see Syntax section above.
 
-    This implementation is not complete. First, because some files in Parser
-    module need to be updated. Second, some additional places aren't 
-    implemented, see Syntax section above.
 
 Discussion
 
@@ -139,16 +151,19 @@ Discussion
     These forms do not look very nice, and in the PEP author's opinion
     do not justify the removal of the lambda keyword in such cases.
 
+
 Credits
 
     The idea of dropping lambda was first coined by Paul Rubin at 08
     Feb 2003 16:39:30 -0800 in comp.lang.python while discussing the
     thread "For review: PEP 308 - If-then-else expression".
 
+
 Copyright
 
     This document has been placed in the public domain.
 
+
 
 Local Variables:
 mode: indented-text
@@ -156,4 +171,3 @@ indent-tabs-mode: nil
 sentence-end-double-space: t
 fill-column: 70
 End:
-