[Python-3000] PEP 3121: Module Initialization and finalization

["Martin v. Löwis"]

Brett,

Thanks for the suggestions; I added them to the PEP.

> How would I raise xx.error in C code now?  I am guessing like this::

Interestingly enough, xxmodule doesn't raise error.

>  PyObject* module = PyState_FindModule(&xxmodule);

Either that, or just use the self parameter if you are in a
module-level function

>  if (!module)
>    return NULL;
>  PyObject* xx_error = xxstate(module)->ErrorObject;
>  if (!xx_error) {
>    PyErr_SetString(PyExc_SystemError, "xx.error missing");
>    return NULL;
>  }

That should not fail. If the module object is still present,
the state shouldn't be cleared normally. So this might
only occur if the code above is invoked in the "clear cycles"
phase of garbage collection.

> Since most objects will move to being memory-managed, one needs to
> worry about checking that the object still exists.  I assume I didn't
> go overboard with the error checking here, right? 

It would be good if the check for the NULL exception object could
be folded in PyErr_SetString (i.e. that raising an internal error
if the exception class is NULL).

> I guess people are
> going to end up writing helper functions to access the various data
> fields as the above would get rather tedious if you had to write it
> more than twice.

Over time, we can try to find convenience macro-functions, e.g.

  PyModule_ObjectField(xxmodule, ErrorObject)

which would return a borrowed reference of type PyObject*, or
NULL (with an exception set) if there is some kind of error.

>> Tim Peters reports in [1]_ that PythonLabs considered such a feature
>> at one point, and lists the following additional hooks which aren't
>> currently supported in this PEP:
>>
>>  * when the module object is deleted from sys.modules
>>
>>  * when Py_Finalize is called
>>
>>  * when Python exits
>>
> 
> Wouldn't the above be covered by the deallocation of the module?

No: deletion from sys.modules might not cause module deallocation,
if there are other references to the module (although Guido might
have meant this mean "module deallocation").

As for finalization/exiting: normally, all modules should be
released before Python exits. Again, if there is some garbage
reference to the module, it may not have been deallocated;
the question then is whether it should get a further opportunity
for cleanup.

Regards,
Martin