Issue 692884: python always searches python23.zip (original) (raw)
Created on 2003-02-25 13:43 by skip.montanaro, last changed 2022-04-10 16:07 by admin. This issue is now closed.
Messages (5)
Author: Skip Montanaro (skip.montanaro) * 
Date: 2003-02-25 13:43
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.
Author: Just van Rossum (jvr) *
Date: 2003-02-25 15:07
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.
Author: Skip Montanaro (skip.montanaro) *
Date: 2003-02-25 15:15
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.)
Author: Just van Rossum (jvr) *
Date: 2003-02-25 15:32
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.
Author: Collin Winter (collinwinter) * 
Date: 2007-03-21 17:18
"python -vv" tells me this was fixed some time between Python 2.4.4 and Python 2.5.0. Closing as "fixed".