iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

editorial tweaks

This commit is contained in:
David Goodger 2003-02-14 14:51:27 +00:00
parent fc14790f4c
commit 512f402bb4
2 changed files with 65 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
pep-0311.txt
View File

@ -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
being called multiple times, the burden this places on extension
authors is considered reasonable.
PyEval_InitThreads(), and as both of these functions currently
support being called multiple times, the burden this places on
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
necessary.
- Get a PyThreadState for the current thread, creating and saving
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
have been made on the current thread.
- Increment a counter for how many calls to
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.

58
pep-0312.txt
View File

@ -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
"lambda" makes code look complex. Omitting lambda in some special
cases is possible, with small and backwards compatible changes to
the grammar, and provides a cheap cure against such "lambdaphobia".
are not used when they would be appropriate, just because the
keyword "lambda" makes code look complex. Omitting lambda in some
special cases is possible, with small and backwards compatible
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
lambda anywhere.
In particular, adding surrounding brackets lets you specify
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
assignment;
* immediately after "=" in named parameter assignment or default
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
to make syntactic and pragmatic changes.
in the Python sources, and some adjustment of
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
lambda may occur, implambdef for the implicit lambda definition itself,
imptestlist for a place where imptest's may occur.
Three new non-terminals are needed: imptest for the place where
implicit lambda may occur, implambdef for the implicit lambda
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: