r55018 - peps/trunk/pep-3121.txt

Author: martin.v.loewis Date: Sun Apr 29 16:17:02 2007 New Revision: 55018 Modified: peps/trunk/pep-3121.txt Log: Add edits suggested by Brett. Modified: peps/trunk/pep-3121.txt ============================================================================== --- peps/trunk/pep-3121.txt (original) +++ peps/trunk/pep-3121.txt Sun Apr 29 16:17:02 2007 @@ -19,8 +19,11 @@ multiple interpreters are not supported well. This PEP addresses these issues. +Problems +======== + Module Finalization -=================== +------------------- Currently, C modules are initialized usually once and then "live" forever. The only exception is when Py_Finalize() is called: then @@ -31,7 +34,7 @@ way to completely release all resources Python has allocated. Entry point name conflicts -========================== +-------------------------- The entry point is currently called init<module>. This might conflict with other symbols also called init<something>. In particular, @@ -40,7 +43,7 @@ _socket). Entry point signature -===================== +--------------------- The entry point is currently a procedure (returning void). This deviates from the usual calling conventions; callers can find out @@ -49,7 +52,7 @@ be the module created, or NULL in case of an exception. Multiple Interpreters -===================== +--------------------- Currently, extension modules share their state across all interpreters. This allows for undesirable information leakage across @@ -97,7 +100,7 @@ PyModuleDef*. The module state will be 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, a function::
participants (1)
-
martin.v.loewis