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

[Brett Cannon]

On 4/29/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> 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
>

OK.

> >  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.
>

Maybe it shouldn't, but can it?  Is there something preventing the
exception object from being cleared beyond people not being stupid?

> > 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).
>

Sounds reasonable.

> > 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.
>

I am sure some will pop up.

> >> 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").
>

You're right.  I was not thinking big enough to consider multiple
imports of the same module.

> 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.

Eh.  I say no for now and if people really need it we can add the hook later.

-Brett