caches are module global in the zip_directory_cache. When it is
updated due to a changed zip file, all zipimporter instances need to
see the same updates TOC cache. This fixes the bug for the overlooked
submodule import case from the earlier round of changes. Includes
tests that would fail otherwise.
It also refactors zipimporter_init in the process to make it a bit
easier to read and understand. Less reuse of the same variable for
multiple purposes and the local path buffer is malloc'ed instead
of consuming a large MAXPATHLEN+2 chunk stack space.
from is modified during the lifetime of the Python process after
zipimport has already opened and cached the zip's table of contents
it now fstat's the file after opening it upon every attempt to access
anything within and will re-read the table of contents if the .zip file
inode, size or mtime have changed.
It would've been nicer to hold any .zip file used by zipimport open for the
duration of the process but that would be more invasive and add an additional
open file descriptor to all zipimport using processes. It also would likely
not fix the problem on Windows due to different filesystem semantics.
arbitrary bytes before the actual zip compatible archive. Zipfiles
containing comments at the end of the file are still not supported.
Add a testcase to test_zipimport, and update NEWS.
This closes sf #775637 and sf #669036.
and test_support.run_classtests() into run_unittest()
and use it wherever possible.
Also don't use "from test.test_support import ...", but
"from test import test_support" in a few spots.
From SF patch #662807.
Fix off-by-1 error in normalize_line_endings():
when *p == '\0' the NUL was copied into q and q was auto-incremented,
the loop was broken out of,
then a newline was appended followed by a NUL.
So the function, in effect, was strcpy() but added two extra chars
which was caught by obmalloc in debug mode, since there was only
room for 1 additional newline.
Get test working under regrtest (added test_main).
Lesson learned: kids should not be allowed to use API's starting
with an underscore :-/
zipimport in 2.3a1 is even more broken than I thought: I attemped
to _PyString_Resize a string created by PyString_FromStringAndSize,
which fails for strings with length 0 or 1 since the latter returns
an interned string in those cases. This would cause a SystemError
with empty source files (and no matching pyc) in the zip archive.
I rewrote the offending code to simply allocate a new buffer and
avoid _PyString_Resize altogether.
Added a test that would've caught the problem.
the test set as it only tested with a zip archive in the current directory,
but it doesn't work at all for packages when the zip archive was specified
as an absolute path. It's a real embarrassing bug: a strchr call should
have been strrchr; fever apparently implies dyslexia.
Second stupid bug: the zipimport test failed with a name error
__importer__ (which I had renamed to __loader__ everywhere but here).
I would've sworn I ran the test after that change but that can't be true.
What I don't understand that noone reported a failing test_zipimport.py
before the release of 2.3a1.
- new import hooks in import.c, exposed in the sys module
- new module called 'zipimport'
- various changes to allow bootstrapping from zip files
I hope I didn't break the Windows build (or anything else for that
matter), but then again, it's been sitting on sf long enough...
Regarding the latest discussions on python-dev: zipimport sets
pkg.__path__ as specified in PEP 273, and likewise, sys.path item such as
/path/to/Archive.zip/subdir/ are supported again.
Benjamin Peterson
Gregory P. Smith
Zachary Ware
Victor Stinner
Ezio Melotti
Georg Brandl
Nick Coghlan
Tim Peters
Phillip J. Eby
Neal Norwitz
Just van Rossum
Thomas Heller
Martin v. Löwis
Walter Dörwald
Jack Jansen