Issue 1666807: Incorrect file path reported by inspect.getabsfile() (original) (raw)

Issue1666807

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) *	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) *	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) *	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) *	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) *	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) *	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.