Issue1605847

classification
Title: co_filename set in bytecode doesn't match __file__
Type: Severity: normal
Components: Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: pjenvey Nosy List: cgroves, leouserz, pjenvey
Priority: normal Keywords:

Created on 2006-11-30.05:23:00 by cgroves, last changed 2009-03-26.14:53:06 by pjenvey.

Messages
msg1351 (view) Author: Charlie Groves (cgroves) Date: 2006-11-30.05:23:00
co_filename in PyFrames comes directly from the created bytecode.  As such, it's set at compile time.  With the update to make __file__ get set at runtime in r2925 these no longer line up.  I'm guessing co_filename should mirror __file__ so that it reflects the actual location of the file.
msg1352 (view) Author: Deleted User leouserz (leouserz) Date: 2007-01-12.18:39:59
this data is stored in a static initialiser in the generated byte code.  If you move the $py.class file around it sticks.  A possible strategy is to remove this string from the static intializer and to define a new static init method that allows the BytecodeLoader to pass in the location from the makeCode method.
msg1353 (view) Author: Deleted User leouserz (leouserz) Date: 2007-01-12.19:17:57
Ok, Id like to attach patch files for a possible solution to this:
#1 we move <clinit> to initialise, a regular method.
#2 we explicitly call initialise with the filename we want to use

this appears to work.  An alternative would be to factor out the PyTableCode creation into its own method and do the same thing.  This seems to be the path of least resistence.
msg1354 (view) Author: Charlie Groves (cgroves) Date: 2007-01-20.17:24:31
The patch is in http://jython.org/patches/1634405
msg1355 (view) Author: Charlie Groves (cgroves) Date: 2007-03-09.17:27:43
Applied the patch in r3138
msg3805 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-22.21:35:50
Came across this bug while attempting to fix __file__ to use the 
compiled filename ( #1138 ).

CPython's co_filename actually doesn't always match __file__, it's 
hardcoded to the original source code filename (at least in 2.5). So we 
actually didn't need to do this:

(jython)pjenvey@golgo13:/tmp$ cat whereami/__init__.py
print 'top level %s' % __file__
def foo():
    pass
print foo.func_code.co_filename
(jython)pjenvey@golgo13:/tmp$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import whereami
top level whereami/__init__.py
whereami/__init__.py
>>> ^D
(jython)pjenvey@golgo13:/tmp$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import whereami
top level whereami/__init__.pyc
whereami/__init__.py
>>> ^D
(jython)pjenvey@golgo13:/tmp$ cd whereami/
(jython)pjenvey@golgo13:/tmp/whereami$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import __init__ 
top level __init__.pyc
whereami/__init__.py
>>> ^D

It's nicer that we did but it requires us to unnecessarily pass in a 
source code filename when loading a class. We already do this for 
__file__, but I'm changing this (__file__ will now always be explicitly 
set by imp instead of having the compiler involved).

Not a big deal, just wanted to document this oddness somewhere =]
msg3829 (view) Author: Philip Jenvey (pjenvey) Date: 2008-11-23.04:59:13
Shoot, this behavior is actually broken -- we need to hardcode this value 
because py_compile.compile allows hardcoding it via the dfile argument. 
Reopening
msg4353 (view) Author: Philip Jenvey (pjenvey) Date: 2009-03-26.14:53:06
Apparently py3k changed to match our behavior:

http://bugs.python.org/issue1180193
http://svn.python.org/view?view=rev&revision=68363

I can't recall if this was actually breaking anything, so closing out
History
Date User Action Args
2009-03-26 14:53:06pjenveysetstatus: open -> closed
resolution: accepted -> fixed
messages: + msg4353
2008-11-23 04:59:13pjenveysetstatus: closed -> open
assignee: pjenvey
resolution: fixed -> accepted
messages: + msg3829
2008-11-22 21:35:51pjenveysetnosy: + pjenvey
messages: + msg3805
2006-11-30 05:23:00cgrovescreate