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

[Jim Fulton]

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