[Patches] [ python-Patches-483466 ] Import from Zip Archive

[noreply@sourceforge.net]

Patches item #483466, was opened at 2001-11-19 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James C. Ahlstrom (ahlstromjc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Import from Zip Archive

Initial Comment:
This is the "final" patch to import.c to support
imports from zip archives and directory caching
using os.listdir().  It replaces patch 476047.  It
it intended to be part of Python 2.3.  There are
five files requiring patches, and these are in
context diff's in five separate attached files.

I have tested this on Linux and Windows 2000.  It
needs testing on bigendian machines, and those with
64-bit integers.  Please complain about bugs, but let
me know if you plan to change the code.

The documentation for the imp module needs a patch.
This is added right after "PY_FROZEN":

PY_ZIPFILE
  The module was found in a zip archive file.

BUGS
====
There are a couple of bugs I wasn't sure were worth
fixing.  Please complain if these are a problem:

The use of os.listdir() for normal directory imports
makes case_ok() unnecessary, but it was not removed.
It might be needed if os.listdir() is missing.

There is no problem if os.listdir() doesn't exist,
but if it exists, it must perform as documented,
and must return both file and directory names in their
correct case.

The PYTHONCASEOK flag is ineffective.  This is a
consequence of dictionary name lookup.

----------------------------------------------------------------------

>Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2001-11-30 08:41

Message:
Logged In: YES 
user_id=64929

I added newer file versions to implement the changes 
discussed on python-dev.  I still need to patch import.c to 
properly handle "" and relative paths in sys.path.  The 
current changes are:

1) Creation of sys.path[0] is moved out of PySys_SetArgv() 
and into Py_GetPath().  Creation of the zip path is also 
moved into Py_GetPath(), so that all sys.path's are now in 
Py_GetPath().
2) sys.path[0] is the absolute path of the Python script 
being run.  For "-c" or an interactive interpreter, it 
remains "".

There are two new Python API functions Py_SetScriptName() 
and Py_GetScriptName().  These are similar to the existing 
Py_[GS]etProgramName() functions, and are used for the same 
purpose, namely passing information to Py_GetPath().  All 
these functions are arguably hacks which should be replaced 
with additional arguments to Py_Initialize().  Here is the 
documentation:

char* Py_GetScriptName ()
Return the script name set with Py_SetScriptName(), or NULL. 
The returned string points into static storage; the caller 
should not modify its value. 

void Py_SetScriptName (char *name)
This is similar to Py_SetProgramName(), but tells the 
interpreter the file name of the Python script being run. 
This is used by Py_GetPath() to add the directory of the 
script to sys.path. If name is NULL no script item is added 
to sys.path.  If name is "", the item "" will be added to 
sys.path, and "" means the current directory.  Otherwise the 
absolute directory path will be added.  The argument must 
point to a string in static storage whose contents will not 
change for the duration of the program's execution.

----------------------------------------------------------------------

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2001-11-20 06:49

Message:
Logged In: YES 
user_id=64929

The zero length string "" is not handled correctly as an 
item of sys.path.  It should mean current directory, but
its contents will not be cached.  What happens if the 
current directory changes?  Should the new directory be 
searched, or only the original current directory?  I will 
submit a further patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470