After wasting a lot of time, I figured it out. Looking under C:\Programs\Python273\Lib
, I noticed that os.pyc
was much smaller in size than os.py
and os.pyo
, while for the other modules, abc.pyc
is equal in size to abc.pyo
and slightly smaller than abc.py
. Looking inside os.pyc
, it contained only:
^Có \{GOc^@^@^@^@^@^@^@^@^A^@^@^@@^@^@^@s^D^@^@^@d^@^@S( ^A^@^@^@N(^@^@^@^@(^@^@^@^@(^@^@^@^@(^@^@^@^@s^_^@^@ ^@C:\Programs\Python273\lib\os.pyt^H^@^@^@<module>^A ^@^@^@s^@^@^@^@
(This is how it shows up in Vim.) (Note: the t
at the end of os.pyt
is not part of the filename.)
Deleting this file (and two other .pyc
files with the same story) solved the problem.
So what happened must be that python
was recompiling os
into os.pyc
for some reason (why? if it's already compiled before?) and has output the first part of the file (which was valid as a file by itself), then the forced shutdown occurred before it had a chance to output the rest. So it's an example of the frustrating problems that happen when operations are not atomic.
Also, it turns out I could have tracked it down faster, because doing
>>> inspect.getfile(os)
'C:\\Programs\\Python273\\lib\\os.pyc'
still works when os.path
isn't available.