Bugs item #692884, was opened at 2003-02-25 08:43 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692884&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: Python Interpreter Core >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Just van Rossum (jvr) Summary: python always searches python23.zip Initial Comment: In trying to figure out why startup of the spambayes hammiefilter seems so slow, I ran it under the control of ktrace (also known as strace or truss on other systems). I noticed that even though it's not in sys.path, the interpreter is always searching for modules in $prefix/python23.zip. Why's that? Here's a little ktrace/kdump output: 2361 python CALL stat(0xbfffe1d0,0xbfffe5e0) 2361 python NAMI "/Users/skip/local/lib/python23.zip" 2361 python RET stat -1 errno 2 No such file or directory 2361 python CALL stat(0xbfffe1d0,0xbfffe5e0) 2361 python NAMI "/Users/skip/local/lib" 2361 python RET stat 0 2361 python CALL stat(0xbfffece0,0xbfffe7d0) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings" 2361 python RET stat -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.py" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.pyc" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.so" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warningsmodule.so" 2361 python RET open -1 errno 2 No such file or directory What's particularly odd is that even though the search for python23.zip fails, it continues to march along looking for files within the nonexistent zip file. Searching for modules in something not in sys.path seems like a bug to me. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:18 Message: Logged In: YES user_id=1344176 Originator: NO "python -vv" tells me this was fixed some time between Python 2.4.4 and Python 2.5.0. Closing as "fixed". ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:32 Message: Logged In: YES user_id=92689 I think it would cause more confusion to have the .pyo's in an earlier location than the .pyc's and .py's. Also, this would cause the .pyo's to always be used, even when not using -O. The solution is what I said: phase two of PEP 302. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-25 10:15 Message: Logged In: YES user_id=44345 If $prefix/python23.zip must always be present and is always going to be searched (and searched ahead of $prefix/python2.3, why not have the installation process create it with the .pyo contents of $prefix/python2.3? (Hammiefilter doesn't import any Mac modules, so the problem Jack fixed shouldn't affect this case.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:07 Message: Logged In: YES user_id=92689 (You probably could have found this with python -vv ;-) Since Python 2.3a1, site.py no longer removes sys.path items that don't exist on the file system, because it may be (eg.) a URL, handled by a custom importer. PEP 273 explains why a standard zip entry must be on sys.path. The problem is that the PEP 302 mechanism doesn't make a difference between "no importer found for this sys.path entry" and "use the builtin path importer". This will be fixed in "phase 2" of PEP 302, which consits of adding an explicit importer object on sys.meta_path representing the builtin path importer. (I should really do this before 2.3b1, this report should serve as a reminder for me.) That said, Jack _yesterday_ fixed a problem on OSX which caused importing Mac modules to be extremely slow (a delay of *seconds*). If spambayes happens to import a Mac module on OSX this would have affected you. Rebuilding from current CVS would help then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692884&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
