Investigating a strange error that I started getting all of a sudden with gdb-python, I reduced it down to this:
C:\Users\User>python -i
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win 32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> dir(os.path)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'path'
>>> dir(os)
['__builtins__', '__doc__', '__file__', '__name__', '__package__']
Looking through some other 'module' object has no attribute
answers, the most common suggestion is that there must be another rogue os.py
somewhere in sys.path
, and that it was getting loaded, rather than the built-in one. But I checked in PYTHONPATH
environment variable, and in the current directory, and there wasn't any other os.py
.
So I looked for a way to find the name of the file where an entity was defined, and unsurprisingly, Python has such a facility in the form of the inspect
module.
>>> inspect.getsourcelines(os)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Programs\Python273\lib\inspect.py", line 690, in getsourcelines
lines, lnum = findsource(object)
File "C:\Programs\Python273\lib\inspect.py", line 527, in findsource
sourcefile = getsourcefile(object)
File "C:\Programs\Python273\lib\inspect.py", line 451, in getsourcefile
if os.path.exists(filename):
AttributeError: 'module' object has no attribute 'path'
So inspect
was relying on os.path
, and then I ran out of ideas.
I haven't installed anything new recently. The only thing that happened was a forced shutdown that I had to do, which might have coincided with running a Python script, since I was running a short Python script in a loop repeatedly when the machine became unresponsive and the forced shutdown occurred.
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.