Erlend E. Aasland <erlend.aasl...@innova.no> added the comment:
Oh, I found PEP 3121 (Extension Module Initialization and Finalization). It is a Standards Track PEP and it is accepted. The abstract is pretty short. Let me just repost it here, for convenience: Extension module initialization currently has a few deficiencies. There is no cleanup for modules, the entry point name might give naming conflicts, the entry functions don't follow the usual calling convention, and multiple interpreters are not supported well. This PEP addresses these issues. Quoting from the Specification section of that PEP: The initialization routine will be invoked once per interpreter, when the module is imported. It should return a new module object each time. In order to store per-module state in C variables, each module object will contain a block of memory that is interpreted only by the module. The amount of memory used for the module is specified at the point of creation of the module. [...] As all Python objects should be controlled through the Python memory management, usage of "static" type objects is discouraged, unless the type object itself has no memory-managed state. PEP 3121 is not withdrawn; PEP 630 is not withdrawn. What is then expected of a new PEP? Or the other way around: what is missing from those two PEPs? AFAICT, PEP wise, everything is arranged and ready. Perhaps the SC can chime in and explain why another PEP is required? :) BTW, the SC has actually asked for another _Informational_ PEP, not a Standards Track PEP, so I guess a new PEP will be very similar to PEP 630? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45113> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
