[Python-Dev] Can we limit the effects of module execution to sys.modules? (was Fix import errors to have data) (original) (raw)

Jim Fulton jim at zope.com
Wed Jul 28 12:56:44 CEST 2004

Tim Peters wrote:

[Jim Fulton] ... ...

Then you're proposing a way for a highly knowledgable user to anticipate, and partially worm around, that Python leaves behind insane module objects in sys.modules. Wouldn't it be better to change Python to stop leaving insane module objects in sys.modules to begin with? That's harder, but seems to me it would do a lot more good for a lot more people.

I sympathize with your frustration with this problem, but I think that the problem is bigger that just sys.modules. For better or worse, importing a module may have side effects that extend beyond sys.modules. For example, In some applications, objects get registered into registries that exist in already-imported modules. Perhaps we want to declare this to be a poor style. If a module has an impact beyond new modules added to sys.modules, then removing all modules imported into sys.modules as a result of attempting the import would produce bugs even more subtle than what we have now.

Do you think it's practical to limit the effects of module import to sys.modules, even by convention? Could we say that it is a bug for code executed during module import to mutate other modules, including mutating objects contained in those other modules? I would support this myself. If it is possible to limit the effects of import (even by convention), then I think it would be practical to roll-back changes to sys.modules. If it's not practical to limit the effects of module import then I think the problem is effectively unsolveable, short of making Python transactional.

Personably I'm inclined to consider errors that occur while executing a module to be pretty much fatal. If a module has begun executing, I really don't know what state it's in or what state it might have left other modules in. I'd rather report the error and get some human to fix it. OTOH, I'm happy to recover from the inability to find a module as long as not module code has been executed.

FWIW, In Zope, we generally generally limit non-transactional state changes to program startup. For that reason, we make little or no attempt to survive startup errors.

Jim

-- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

More information about the Python-Dev mailing list