On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
