This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Incorrect file path reported by inspect.getabsfile()
Type: Stage:
Components: Library (Lib) Versions: Python 3.11
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: EwoutH, collinwinter, fer_perez, gvanrossum, jerry.seutter, zseil
Priority: normal Keywords:

Created on 2007-02-23 07:08 by fer_perez, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (12)
msg31310 - (view) Author: Fernando Pérez (fer_perez) Date: 2007-02-23 07:08
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.
msg31311 - (view) Author: Fernando Pérez (fer_perez) Date: 2007-02-23 16:57
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
msg31312 - (view) Author: Jerry Seutter (jerry.seutter) * (Python committer) Date: 2007-02-24 06:51
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?
msg31313 - (view) Author: Fernando Pérez (fer_perez) Date: 2007-02-24 07:22
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!
msg31314 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-09 00:04
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?
msg31315 - (view) Author: Fernando Pérez (fer_perez) Date: 2007-03-09 02:00
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.
msg31316 - (view) Author: Ziga Seilnacht (zseil) * (Python committer) Date: 2007-03-16 14:06
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
msg31317 - (view) Author: Fernando Pérez (fer_perez) Date: 2007-03-18 23:49
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.
msg31318 - (view) Author: Ziga Seilnacht (zseil) * (Python committer) Date: 2007-04-03 07:15
Ok, this is the same problem as reported in bug #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. 
msg414454 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-03-03 16:06
So this bug is referenced when pydevd encounters some problem with 3.11a5+:

https://github.com/fabioz/PyDev.Debugger/issues/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?
msg416925 - (view) Author: Ewout ter Hoeven (EwoutH) Date: 2022-04-07 12:26
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
-------------------------------------------------------------------------------
msg416932 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-04-07 15:25
@Ewout, the current workaround (until pydevd is fixed) is to add -Xfrozen_modules=off to the Python command line.
History
Date User Action Args
2022-04-11 14:56:22adminsetgithub: 44604
2022-04-07 15:25:46gvanrossumsetmessages: + msg416932
2022-04-07 12:26:54EwoutHsetnosy: + EwoutH

messages: + msg416925
versions: + Python 3.11, - Python 2.5
2022-03-03 16:06:17gvanrossumsetnosy: + gvanrossum
messages: + msg414454
2007-02-23 07:08:51fer_perezcreate