imp.reload() and importlib.reload() docs state::

    If a module is syntactically correct but its initialization fails, the first
    :keyword:`import` statement for it does not bind its name locally, but does
    store a (partially initialized) module object in ``sys.modules``.  To reload
    the module you must first :keyword:`import` it again (this will bind the name
    to the partially initialized module object) before you can :func:`reload` it.

If I reading that correctly, "initialization" refers to executing the module, so for module containing just::

    uninitialized_variable

the following::

    >>> import sys
    >>> import x
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/tmp/x.py", line 1, in <module>
        uninitialized_variable
    NameError: name 'uninitialized_variable' is not defined

should leave me with a initialized module in sys.modules['x']. However, this is not what happens, in either Python 3.4 or 2.7::

    >>> sys.modules['x']
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    KeyError: 'x'

Here's a patch to remove the caveat in Python 3 docs.
If I missed something, and "initialization" refers to something else, it should be clarified.

This generally comes up in the context of a module importing another module, and *that* module fails to import.  The first module is left in sys.modules as a stub.  Try that experiment, I'm pretty sure that is still true.

Not true (on 3.3 & 2.7).

>>> import sys
>>> import x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/x.py", line 1, in <module>
    import y
  File "/tmp/y.py", line 1, in <module>
    1/0
ZeroDivisionError: division by zero
>>> sys.modules['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'x'
>>> sys.modules['y']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'y'

For 3.4, PEP 451 explicitly specifies ``del sys.modules[spec.name]`` if ``loader.exec_module`` fails [0].

[0] https://www.python.org/dev/peps/pep-0451/#how-loading-will-work

OK, I can't reproduce it either, neither in python3 nor python2.  Brett, is this left over from a long time ago?

Heh.  I just tried another experiment and got an interesting result:

rdmurray@pydev:~/python/p34>cat temp1.py
import temp2
foo = 1
rdmurray@pydev:~/python/p34>cat temp2.py
import temp1

badval

rdmurray@pydev:~/python/p34>./python
Python 3.4.3+ (3.4:b53cfcfdfe47, May  2 2015, 12:51:46) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import temp2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/p34/temp2.py", line 3, in <module>
    badval
NameError: name 'badval' is not defined
>>> import sys
>>> sorted(sys.modules.keys())
['__main__', '_codecs', '_collections_abc', '_frozen_importlib', '_imp', '_io', '_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'atexit', 'builtins', 'codecs', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath', 'readline', 'rlcompleter', 'signal', 'site', 'stat', 'sys', 'sysconfig', 'temp1', 'zipimport']
>>> import temp1
>>> temp1.temp2
<module 'temp2' from '/home/rdmurray/python/p34/temp2.py'>
>>> sorted(sys.modules.keys())
['__main__', '_codecs', '_collections_abc', '_frozen_importlib', '_imp', '_io', '_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'atexit', 'builtins', 'codecs', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath', 'readline', 'rlcompleter', 'signal', 'site', 'stat', 'sys', 'sysconfig', 'temp1', 'zipimport']


More or less the reverse of the passage in question.

Note that calling reload on temp1.temp2 will fail with an error that temp2 is not in sys.modules.  So maybe the caveat needs rewording rather than deletion.

Either the docs are out-of-date or they are really poorly worded.  Most likely it's the former, but I'm taking a look.

I've verified that the documentation is correct under Python 2.3.  The behavior changed under Python 2.4 (and the docs were not updated).  I expect that the change in behavior is an unintended consequence of a change in the import system for 2.4.  There were 7 in 2.4, so I'm checking to see which did it.

FYI, our backward-compatibility policy would preclude a change like this, which is why I think it was unintentional.  That no one noticed implies that we did not have a unit test for the case and that folks really weren't relying on the behavior anyway (at least not enough to open a bug). :)  I suppose there could be an old bug on this, but if that the case then someone decided not to change it back.

Regardless, the docs should be fixed by removing the referenced paragraph.

I'm pretty sure this is the culprit:

changeset:   32882:331e60d8ce6da19b168849418776fea0940787ec
branch:      legacy-trunk
user:        Tim Peters <tim.peters@gmail.com>
date:        Mon Aug 02 03:52:12 2004 +0000
summary:     PyImport_ExecCodeModuleEx():  remove module from sys.modules in error cases.

patch LGTM for the 3 branches.

New changeset 3cdeafd18e61 by R David Murray in branch '3.4':
#24081: Remove obsolete caveat from import docs.
https://hg.python.org/cpython/rev/3cdeafd18e61

New changeset d57e0c6d292d by R David Murray in branch 'default':
Merge: #24081: Remove obsolete caveat from import docs.
https://hg.python.org/cpython/rev/d57e0c6d292d

New changeset fd1549dd8065 by R David Murray in branch '2.7':
#24081: Remove obsolete caveat from import docs.
https://hg.python.org/cpython/rev/fd1549dd8065

Thanks, Petr.  (And Eric.)

I vaguely recall discussing that change, and my recollection is that it was
deliberate in order to evict improperly configured modules - we didn't
count it as a significant compatibility break because it solely affected an
error handling path.

I guess we never thought to check if the old misbehaviour was formally
documented.