The following code demonstrates the problem succinctly:

###
import inspect,sys

print 'Version info:',sys.version_info
print

f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print 'File for `inspect`       :',f1
print 'File for `inspect.iscode`:',f2
print 'Do these match?',f1==f2
if f1==f2:
    print 'OK'
else:
    print 'BUG - this is a bug in this version of Python'

### EOF

Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py
Version info: (2, 3, 6, 'final', 0)

File for inspect : /home/fperez/tmp/local/lib/python2.3/inspect.py
File for inspect.iscode: /home/fperez/tmp/local/lib/python2.3/inspect.py
Do these match? True
OK
tlon[bin]> python2.4 ~/code/python/inspect_bug.py
Version info: (2, 4, 4, 'candidate', 1)

File for inspect : /usr/lib/python2.4/inspect.py
File for inspect.iscode: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python
tlon[bin]> python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for inspect : /usr/lib/python2.5/inspect.py
File for inspect.iscode: /home/fperez/tmp/local/bin/inspect.py
Do these match? False
BUG - this is a bug in this version of Python

The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code:

###
import inspect,sys

print 'Python version info:',sys.version_info
print 'File info for inspect.iscode function:'
print ' ',inspect.iscode.func_code.co_filename
print

EOF

shows the problem:

tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py
Python version info: (2, 3, 6, 'final', 0)
File info for inspect.iscode function:
/home/fperez/tmp/local//lib/python2.3/inspect.py

tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for inspect.iscode function:
inspect.py

(2.4 has the same issue).

Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days.

Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there:

import inspect
print 'File for `code`         :',inspect.getabsfile(code)
print 'File for `code.interact`:',inspect.getabsfile(code.interact)

Gives:

File for code :
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py
File for code.interact:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py

My original tests were done under Ubuntu Edgy Eft, using the Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source download at python.org.

HTH,

f

Hi,

On a custom-compiled Python 2.5 on Ubuntu Dapper, I get:
yello@outback:~/code/python $ python bug_1666807.py
Version info: (2, 5, 0, 'final', 0)

File for inspect : /usr/local/lib/python2.5/inspect.py
File for inspect.iscode: /usr/local/lib/python2.5/inspect.py
Do these match? True
OK

On a system python 2.4.3 on another Ubuntu Dapper system, I get:
yello@adelaide:~/code/python $ python bug_1666807.py
Version info: (2, 4, 3, 'final', 0)

File for inspect : /usr/lib/python2.4/inspect.py
File for inspect.iscode: /usr/lib/python2.4/inspect.py
Do these match? True
OK

However, I can recreate this issue on another system (CentOS4) with a custom install where a symlink is involved. I get:
[prompt goes here python]$ python bug_1666807.py
Version info: (2, 2, 3, 'final', 0)

File for inspect : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py
File for inspect.iscode: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py
Do these match? 0
BUG - this is a bug in this version of Python

Is a symlink involved on the system where you saw this behaviour?

No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get:

tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py
Version info: (2, 5, 0, 'final', 0)

File for inspect : /home/fperez/tmp/local/lib/python2.5/inspect.py
File for inspect.iscode: /home/fperez/tmp/local/lib/python2.5/inspect.py
Do these match? True
OK

tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py
Python version info: (2, 5, 0, 'final', 0)
File info for inspect.iscode function:
/home/fperez/tmp/local//lib/python2.5/inspect.py

So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made.

At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know.

But the end-user behavior /is/ a bug, so it would be nice to know how to fix it.

Thanks for your info!

I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux).

What options are you providing to ./configure?

As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info.

There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it.

It looks like this is a bug in Ubuntu build process.
The logging package had the same problem:
http://www.python.org/sf/1669498
http://www.python.org/sf/1633605
http://www.python.org/sf/1616422

Yes, though at least in this report we seem to have narrowed down the problem a little better.

I'm perfectly willing to believe that Ubuntu is somehow mis-building their shipped Python, but it would be great if the Python build itself could be hardened against this being possible in the first place.

Unfortunately I don't know how to better track the problem, but I'll be glad to provide info from my local system upon request.

Ok, this is the same problem as reported in bug bpo-1180193:

http://www.python.org/sf/1180193

The reporter of that bug is willing to write a patch, so
I think it is better to close this one as a duplicate.

So this bug is referenced when pydevd encounters some problem with 3.11a5+:

fabioz/PyDev.Debugger#213

Since the link to this bug is apparently baked into the error messages printed by pydevd, I am adding this comment to this old, closed bug.

I can't seem to reproduce it. I modernized the reproducer script:

import inspect,sys

print('Version info:',sys.version_info)
print()

f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print('File for `inspect`       :',f1)
print('File for `inspect.iscode`:',f2)
print('Do these match?',f1==f2)
if f1==f2:
    print('OK')
else:
    print('BUG - this is a bug in this version of Python')

###EOF

And the output is:

Version info: sys.version_info(major=3, minor=11, micro=0, releaselevel='alpha', serial=5)

File for inspect : c:\users\gvanrossum\appdata\local\programs\python\python311\lib\inspect.py
File for inspect.iscode: c:\users\gvanrossum\appdata\local\programs\python\python311\lib\inspect.py
Do these match? True
OK

I tried it with the most recent Python built from source and get the same result:

Version info: sys.version_info(major=3, minor=11, micro=0, releaselevel='alpha', serial=5)

File for inspect : c:\users\gvanrossum\cpython\lib\inspect.py
File for inspect.iscode: c:\users\gvanrossum\cpython\lib\inspect.py
Do these match? True
OK

So I wonder if the problem that's currently plagueing pydevd in 3.11 alpha releases is slightly different?

When running anything with a freshly installed version of Python 3.11.0a7 on 64-bit Windows, the following message is printed:

-------------------------------------------------------------------------------
pydev debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute)
pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints.
pydev debugger: Related bug: http://bugs.python.org/issue1666807
-------------------------------------------------------------------------------

@ewout, the current workaround (until pydevd is fixed) is to add -Xfrozen_modules=off to the Python command line.