This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Pascal.Chambon, brett.cannon, eric.snow, ncoghlan
Date 2013-04-14.08:29:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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 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

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.
Date User Action Args
2013-04-14 08:29:37ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.snow, Pascal.Chambon
2013-04-14 08:29:37ncoghlansetmessageid: <>
2013-04-14 08:29:37ncoghlanlinkissue17716 messages
2013-04-14 08:29:36ncoghlancreate