[Python-Dev] clarifying PEP 302 loader responsibilities upon failure (original) (raw)
Guido van Rossum guido at python.org
Mon Feb 9 23:02:13 CET 2009
- Previous message: [Python-Dev] clarifying PEP 302 loader responsibilities upon failure
- Next message: [Python-Dev] clarifying PEP 302 loader responsibilities upon failure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Feb 9, 2009 at 1:56 PM, <bcannon at gmail.com> wrote:
Guido and I were discussing what a loader should be responsible for when loadmodule is called and an exception is raised in relation to sys.modules as PEP 302 says nothing about the topic.
We both agree that if the loader added a module to sys.modules it should be removed, otherwise it should be left alone. Assuming no one disagrees I will update the PEP to specify that this is the expected job of loaders.
(Note that currently most loaders we've looked at end up removing the module unconditionally, as this is what PyImport_ExecCodeModuleEx() does. PyImport_ReloadModule() has a super-duper hack to save the module object and put it back into sys.modules:
if (newm == NULL) {
/* load_module probably removed name from modules because of
* the error. Put back the original module object. We're
* going to return NULL in this case regardless of whether
* replacing name succeeds, so the return value is ignored.
*/
PyDict_SetItemString(modules, name, m);
}
If we could get conforming loaders to behave as proposed, we wouldn't need this ugly hack.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] clarifying PEP 302 loader responsibilities upon failure
- Next message: [Python-Dev] clarifying PEP 302 loader responsibilities upon failure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]