Nick Coghlan added the comment: More generally, I think we may have to revisit the question of what we remove from sys.modules on failure if, as a side effect of the import, a child module was imported successfully.
In this situation, the possibilities are: 1. Remove the parent module, and all child modules. We don't currently do this because importing the child modules may have had side effects. However, I'm not sure this reasoning is sound, as the section of __init__.py before the failure may have had side effects too, and we don't let that stop us from removing the parent module. 2. Remove just the parent module. That's what we currently do, and it's a problem because we're knowingly breaking one of the import state invariants (i.e. if a non top-level module is present in sys.modules, then all parent modules in the chain can be assumed to also be in sys.modules) 3. Leave the partially initialised parent module in sys.modules as well. This would be a bad idea, since it would lead to very inconsistent behaviour as to whether or not the parent module was left in sys.modules based on the contents of __init__.py To be honest, I think purging the entire subtree (option 1 above) would be better than what we do now - breaking state invariants is bad, because it can lead to surprising errors a long way from the actual source of the problem. ---------- versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17716> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
