Bugs item #1309567, was opened at 2005-09-30 10:57 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) >Summary: linecache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-09-30 13:12 Message: Logged In: YES user_id=11105 > But what about the use case of modules compiled on one system > and moved to a different system? Is that use case important > enough? Maybe. Couldn't the code be made more robust, so that it works as intended with packages? Unfortunately the code objects don't have a reference to the module where they live (probably because they are created before the module is created). BTW: The bug sometimes also is responsible for tracebacks in pydoc, because it cannot locate the sourceline in the file. So, wrong sourec in tracebacks aren't the only problem. It seems it would work better with relative pathnames, but it's too late for that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-30 12:24 Message: Logged In: YES user_id=6380 Radical indeed. But what about the use case of modules compiled on one system and moved to a different system? Is that use case important enough? There used to be a different use case, because bytecode files used to contain relative path names. I believe that's been fixed, if only by code in site.py that absolutizes sys.path. (Except the initial '' -- is that important?) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-09-30 11:08 Message: Logged In: YES user_id=11105 The attached patch is a radical way to fix this problem - it refuses to guess if the file is not found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
