Add edits suggested by Brett.

This commit is contained in:
Martin v. Löwis 2007-04-29 14:17:02 +00:00
parent d4d0b01433
commit 06bca6e5e3
1 changed files with 8 additions and 5 deletions

View File

@ -19,8 +19,11 @@ the entry functions don't follow the usual calling convention, and
multiple interpreters are not supported well. This PEP addresses these multiple interpreters are not supported well. This PEP addresses these
issues. issues.
Problems
========
Module Finalization Module Finalization
=================== -------------------
Currently, C modules are initialized usually once and then "live" Currently, C modules are initialized usually once and then "live"
forever. The only exception is when Py_Finalize() is called: then forever. The only exception is when Py_Finalize() is called: then
@ -31,7 +34,7 @@ is no way to reclaim them. As a result, there is currently no
way to completely release all resources Python has allocated. way to completely release all resources Python has allocated.
Entry point name conflicts Entry point name conflicts
========================== --------------------------
The entry point is currently called init<module>. This might conflict The entry point is currently called init<module>. This might conflict
with other symbols also called init<something>. In particular, with other symbols also called init<something>. In particular,
@ -40,7 +43,7 @@ problem got resolved as a side effect of renaming the module to
_socket). _socket).
Entry point signature Entry point signature
===================== ---------------------
The entry point is currently a procedure (returning void). This The entry point is currently a procedure (returning void). This
deviates from the usual calling conventions; callers can find out deviates from the usual calling conventions; callers can find out
@ -49,7 +52,7 @@ PyErr_Occurred. The entry point should return a PyObject*, which will
be the module created, or NULL in case of an exception. be the module created, or NULL in case of an exception.
Multiple Interpreters Multiple Interpreters
===================== ---------------------
Currently, extension modules share their state across all Currently, extension modules share their state across all
interpreters. This allows for undesirable information leakage across interpreters. This allows for undesirable information leakage across
@ -97,7 +100,7 @@ Creation of a module is changed to expect an optional
PyModuleDef*. The module state will be PyModuleDef*. The module state will be
null-initialized. null-initialized.
Each module method with be passed the module object Each module method will be passed the module object
as the first parameter. To access the module data, as the first parameter. To access the module data,
a function:: a function::