TL;DR: don't do anything involving side-effects as part of an import that can fail like connecting to a database. Another bug that proposes tweaking the IMPORT_FROM bytecode semantics will more than likely solve your problem regardless.


First question: what versions of Python did you test this against? You didn't specify the version when you filed the bug.

Second, if you want to see how it all works, import is implemented in pure Python in Python 3.3 so you can actually read the code if you want: http://hg.python.org/cpython/file/185ae0c95e5b/Lib/importlib/_bootstrap.py. I also gave a talk at PyCon US 2013 (and PyCon Argentina) on how import works if you are curious: http://pyvideo.org/video/1707/how-import-works.

Third, performing operations as a side-effect of import which could cause a failure is a dodgy practice, as you have found out. I would advise looking for a way to not trying to connect to your database as part of an import so that the import will succeed consistently and you won't have this problem.

Fourth, everything is working as intended. We can't roll back imports because of possible side-effects you do during import, so we can't have pkg.module_a successfully import but then toss it aside just because pkg succeeds. And the from ... import format fails as it does on the second import because as you pointed out, pkg.module_a is not an attribute on pkg. The attempted import succeeds internally since pkg.module_a is just sitting there in sys.modules, but it isn't explicitly re-attached to pkg as that's not expected if the first import failed thanks to pkg failing but you choose to attempt to ignore that fact (so it should honestly fail). The bytecode uses getattr() on the module so there is no specific reason for it to think it should work. But when you do a straight import that succeeds as that will do the necessary binding to pkg.

Fifth, http://bugs.python.org/issue17636 will probably make all of this a moot point. =) That issue is tracking a proposed change which will cause from ... import to pull from sys.modules if a module is in sys.modules but not attached on a module to deal with circular imports. But I think as a side-effect it will also help deal with your problem based on what you have described.

Sixth, if you want to help clarify the docs for Python 3.3 and 2.7 that would be great! Just open a new bug with a patch for the doc changes and I would be happy to review it.