[ python-Bugs-692884 ] python always searches python23.zip

[SourceForge.net]

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