[ python-Bugs-415492 ] Compiler generates relative filenames

SourceForge.net noreply at sourceforge.net
Tue Apr 26 23:54:11 CEST 2005


Bugs item #415492, was opened at 2001-04-11 14:52
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=415492&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler generates relative filenames

Initial Comment:
Make a file called "test.py"
----
import pack

print pack.func.func_code.co_filename
-----

Make a directory called "pack". Put a file in it 
called "__init__.py" with the contents:

def func(): pass

Now run test.py. It will compile a relative path into 
these modules. Now you can change to any directory on 
the system and run test.py and it will return the 
original relative path. The problem is that the 
relative path is compiled into the .pyc. It should be 
an absolute path.

----------------------------------------------------------------------

>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-04-26 17:54

Message:
Logged In: YES 
user_id=593130

Closing as fixed, on the basis of isandlers report, until someone 
verifies that it is a current problem.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2005-04-23 00:02

Message:
Logged In: YES 
user_id=971153

I tried to reproduce the problem with python 2.4 and I'm
getting the absolute path....

So, I guess, the bug can be closed

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-04-25 17:08

Message:
Logged In: YES 
user_id=86307

I just ran into this today when trying to find out why 
pydoc wasn't working for a module of mine: 
inspect.getmodule calls os.abspath with the filename found 
in the code object of global functions.  If the cwd is 
different than when the code object was compiled, 
inspect.getmodule fails.

Anyway, it looks to me like most of these relative paths 
could be caught in the find_module function (of import.c) 
if, when given an empty string for a path (while iterating 
over sys.path), find_module called getcwd() and used that 
instead of the empty string.  Of course, this assumes that 
(on all platforms) opening a bare filename means open the 
file with that name in the current directory (is that a 
valid assumption?).  Also, it appears from posixmodule.c 
that getcwd may not always be available.

Does this sound like a reasonable idea?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:10

Message:
Logged In: YES 
user_id=6380

Why on earth was this assigned to Paul? He's not going to
make progress. Assigning back to nobody.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 17:15

Message:
Logged In: YES 
user_id=31392

Just to clarify.  The compiler in question is the builtin
compiler.  It generates absolute path names unless the .py
file is in the current working directory.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 10:12

Message:
Logged In: YES 
user_id=31392

I'm not clear on what the rules for co_filename are, but it
looks like the absolute path is only used for package
imports.  If you cd into the package directory, run python
-c "import __init__", and then later import the package the
path name is relative.

The compiler package isn't connected to the import
mechanism, so there's no way for it to know whether it is
compiling a module or a package.  I don't think there's a
way to do anything better.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=415492&group_id=5470


More information about the Python-bugs-list mailing list