[Patches] [ python-Patches-645650 ] Import from Zip Archive
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 01 Dec 2002 15:00:43 -0800
Patches item #645650, was opened at 2002-11-29 12:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Import from Zip Archive
Initial Comment:
This patch supersedes patch 492105.
This is an updated version of the patch for imports from
a zip file. This version is against current CVS, and
includes documentation and tests.
The patch builds on Windows, and runs OK. I haven't
(yet) run any comprehensive tests, as this is the first
time I've set up a build environment, and I'm not sure
how to run the tests yet :-(
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2002-12-02 00:00
Message:
Logged In: YES
user_id=21627
I certainly agree with only treating .zip as indication for
zipfiles. On a case insensitive file system, you can put
.zip into sys.path and it will still find .ZIP.
----------------------------------------------------------------------
Comment By: Paul Moore (pmoore)
Date: 2002-12-01 23:34
Message:
Logged In: YES
user_id=113328
I've now taken Neal's patch and integrated my changes. I'll
check it through again, and run a few more tests, and then
upload the result (I've had problems with cvs update, so I'm
downloading a new copy of CVS python first).
Most things look OK. There are a couple of issues with case-
insensitive filesystems.
The first is that the cache of os.listdir results is (case-
sensitively) keyed on directory name. I don't see this as an
issue as (a) I'd expect the case used to remain constant
(who's going to change a directory in sys.path at runtime to
the same name with a different case???) and (b) it's only an
efficiency hit, not an error, in any case.
The second issue is more problematic. Zip files on sys.path
are recognised (see add_zip_names()) by the extension ".zip"
(case sensitively). It's arguable that on case-insensitive
filesystems, this check should also be case insensitive. But
finding that a file is on a case-insensitive filesystem is, I
believe, not possible. And using a case-insensitive test all the
time isn't right either. I'd say that we should just *define* the
algorithm as only treating files ending in ".zip" (case
sensitive) as zip files. It doesn't seem to be a problem in
practice.
I'll try to find some way to fit that into the documentation...
Apart from this issue, I've seen no other problems with the
patch.
----------------------------------------------------------------------
Comment By: Paul Moore (pmoore)
Date: 2002-11-29 22:11
Message:
Logged In: YES
user_id=113328
My problem turns out to be an interaction with the
new "universal newline support". In find_module, within the
switch(path_type), case PY_IMP_LISTDIR, the section of
code marked /* Search the list of suffixes: .pyc, .pyd, ... */
tries to do fopen(buf, fdp->mode). But .py files are now
mode 'U' (universal newline) which is not a valid mode for fopen
(). I've made a fix, but I'm not sure how reliable it is.
On a related note, I'm not 100% sure how robust the code is
in the presence of case-insensitive filesystems. I'm way out of
my depth in this code, so I don't know if I'll be able to fix it,
but I'll have a look (and I'll look at your version of the patch, as
well).
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-29 19:47
Message:
Logged In: YES
user_id=33168
Paul, thanks for taking this up. I made very little
progress on this I have attached my version of the diffs.
I had some problems with the original patch which I was
never able to correct. For example, I think it was not
possible to run python from a local build env't. It
appeared that python had to be installed for everything to
work. See the problem in bug 586680 (also in site.py).
That should probably be addressed and was part of my problem.
I tried to simplify the code some, so you should see some
differences between the patch I attached and the original.
These are not as important as making the patch work
properly, both when installed and running from a build env't.
I will try to take a look at your problem later, but it may
take a while. Let me know if you make progress.
----------------------------------------------------------------------
Comment By: Paul Moore (pmoore)
Date: 2002-11-29 12:57
Message:
Logged In: YES
user_id=113328
Bad news. I've just hit problems with the patched Python -
when I start python.exe, it reports "cannot import site" and
seems unable to locate the standard library. (This when I run
python from the PCBuild directory).
I built a clean CVS version, and don't see this problem.
Can anyone else reproduce this, or help me diagnose it? I
don't understand Jim's changes well enough to see what
might be the problem (I updated the patch purely
mechanically).
----------------------------------------------------------------------
Comment By: Paul Moore (pmoore)
Date: 2002-11-29 12:40
Message:
Logged In: YES
user_id=113328
Uploaded file foo.zip, needed (in lib\test directory) for the
changes to test_import.py
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470