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

Proofread before posting to python-ideas

This commit is contained in:
Nick Coghlan 2012-12-28 01:10:05 +10:00
parent 575cf00896
commit 6c032178b4
1 changed files with 17 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
pep-0432.txt
View File

@ -238,11 +238,12 @@ to be used safely for all of the remaining configuration steps (unlike the
status quo).
In addition, the current thread will possess a valid Python thread state,
allow any further configuration data to be stored.
allow any further configuration data to be stored on the interpreter object
rather than in C process globals.
Any call to Py_InitStart() must have a matching call to Py_Finalize(). It
is acceptable to skip calling Py_InitFinish() in between (e.g. if
attempting to read the configuration settings fails)
Any call to Py_BeginInitialization() must have a matching call to
Py_Finalize(). It is acceptable to skip calling Py_EndInitialization() in
between (e.g. if attempting to read the configuration settings fails)
Determining the remaining configuration settings
@ -343,6 +344,11 @@ are currently read lazily may instead be read once during interpreter
initialisation. As the PEP matures, these will be discussed in more detail
on a case by case basis.
The Py_Initialize() style of initialisation will continue to be supported. It
will use the new API internally, but will continue to exhibit the same
behaviour as it does today, ensuring that sys.argv is not set until a
subsequent PySys_SetArgv call.
A System Python Executable
==========================
@ -364,14 +370,14 @@ sounds good in theory but proves to be problematic in practice.
One final aspect not addressed by the general embedding changes above is
the current inaccessibility of the core logic for deciding between the
different execution modes supported by CPython::
different execution modes supported by CPython:
* script execution
* directory/zipfile execution
* command execution ("-c" switch)
* module or package execution ("-m" switch)
* execution from stdin (non-interactive)
* interactive stdin
* script execution
* directory/zipfile execution
* command execution ("-c" switch)
* module or package execution ("-m" switch)
* execution from stdin (non-interactive)
* interactive stdin
<TBD: concrete proposal for better exposing the __main__ execution step>