8

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.

Community
  • 1
  • 1
Evgeni Sergeev
  • 22,495
  • 17
  • 107
  • 124

2 Answers2

6

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.

Evgeni Sergeev
  • 22,495
  • 17
  • 107
  • 124
0

I have the same problem and C:\Python27\Lib\os.py doesn't have readlink() function at all. Searched the Lib and found 6 paces there it's being used but no definition:

Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32

C:\Python27\Lib\pdb.py(1194):                 dirname = os.readlink(dirname)
C:\Python27\Lib\platform.py(952):             os.path.join(os.path.dirname(filepath),os.readlink(filepath)))
C:\Python27\Lib\posixpath.py(386):         resolved = os.readlink(path)
C:\Python27\Lib\rexec.py(146):     ok_posix_names = ('error', 'fstat', 'listdir', 'lstat', 'readlink',
C:\Python27\Lib\shutil.py(183):                 linkto = os.readlink(srcname)
C:\Python27\Lib\tarfile.py(1873):             linkname = os.readlink(name)
ZXX
  • 4,684
  • 27
  • 35