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.

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.

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.)

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.

"python -vv" tells me this was fixed some time between Python 2.4.4 and Python 2.5.0. Closing as "fixed".