homepage

No one wants to work on zipimport, and yet it's full of bugs. It needs a rewrite so that it's more maintainable. An idea floated at PyCon 2015 was to writing the zip-reading code in C and to keep it as simple as possible -- e.g., don't worry about supporting comments, etc. -- and then write the rest of the code in importlib, making maintenance much easier.
All of the various zipimport bugs should be made dependent on this issue as unless they are critical flaws I doubt they will get fixed without the rewrite.

FYI I'm at the early stage of rewriting zipimport in Python.

Are you writing it in such a way that it can be bootstspped in with importlib so the stslib can be loaded from it?

It was my intention.

Serhiy, how far along are you on this? I have a wip from this summer that I could finish over the holidays.

I were on very early stage, and stopped this work few weeks ago in favor of other issues. I would be glad to make a review of your work when you have finished it Rose.

Can you both publish your WIP work?

What are people's statuses on their various attempts? Since this is going to block my importlib.resources work I will do the work myself or work directly with someone in order to make sure this gets done.

Sorry for the late response. I didn't have much time over the holidays. I think I better let someone else take this one.

Here is preliminary translation of zipimport to Python. It is not frozen and imports other modules. I tried to keep the implementation close to C implementation. As a consequence, some raised exceptions look arbitrary.

Got rid of dependencies from os, stat and encodings.

> Here is preliminary translation of zipimport to Python. It is not frozen and imports other modules.
Technically, will it be possible to freeze it? It seems useful to keep the ability to put the whole stdlib into a single ZIP. Using a ZIP is sometimes suggested to avoid fstat() on disk for example, to speedup Python startup.
But I also understand that the C code is painful to maintain and update.
Anyway, nice job Serhiy :-)

So long as this code block that imports os is avoided, I believe that this can be properly frozen:
+ if not isinstance(path, str):
+ import os
+ path = os.fsdecode(path)
But it should be easy to avoid that code path when the standard library is a zip file.
Otherwise it uses importlib (frozen), marshal (builtin), sys (builtin), time (builtin), and zlib [if present] (extension module).

> Technically, will it be possible to freeze it?
I think yes. But I don't know how to do this. I hope on Brett's (or other import machinery expert) help.
Since zipimporter constructor is called only with string path by import machinery, the os module is not imported at initialization stage.

And having a private copy of os.fsdecode() isn't difficult as os.fspath() is in posix and after that it's four lines that only need access to the sys module.

Just FYI, if this lands I will probably try to build off of it to make a pathlib-like zip module to eventually replace zipfile. So if there's any API design decisions that need to be made, it would be great if we try to keep the zip-specific bits separate and generic enough to work with in other future libraries.

What is the status of this work? Is there anything I can do to help make this happen?

I've landed here after chatting with @brett.cannon. I have a use case for this (making pex startup faster by bypassing pkg_resources) but I need to hack around the limitation of dlopen'ing .so's from zips. Our idea was to have a zipimport subclass which doesn't return None from `importlib.util.find_spec()` when it finds a .so, but instead dumps that into some safe directory, and then arranges for a loader that knows how to load that. It sure would be handy for this to be a zipimporter subclass. :)
I think Serhiy's patch predates the move to GitHub, so it's not a branch/PR. I guess the next step would be to branchify the patch and then continue discussion over there. Depending on my availability, I might do that.

I've ported the patch to a branch on GH. See PR 4023. I started from zipimport-2.patch. It doesn't work, but it will be easier to work on as a PR rather than a patch.
Contributions welcome! Let's see if we can make this work.

So, after reviewing this it started to make me rethink about the zipimport.py file.
So my question is how would that file work if it is an pyc file in python37.zip or something just to zipimport other modules? There is got to be some sort of low level api that can zip import the zip importer then on the rewrite. Am I right?
Maybe the best bet is to wait for bug reports on the C Code and fixup the C Code if possible so that way there is no conflicts like the ones I just questioned.

zipimport.py would be frozen just like importlib, so there's no bootstrapping issue if that's what you're asking.

Alright, just wanted to make sure because I did not want to have something break when loading up the entire standard library from an zip file with it.

PR 6809 freezes zipimport.py, adds changes made in zipimport.c since writing the initial Python implementation, and fixes few bugs exposed in the frozen module. Seems Python now works with the zipped stdlib.

Could anybody please make a review? This is just a first step, we need to do it before making other steps: implementing more modern import API, supporting large ZIP files and ZIP files with comments, implementing loading binary extensions from ZIP files, etc.

I'm planning to review the PR at some point.
On Sun, Jul 8, 2018, 00:42 Serhiy Storchaka, <report@bugs.python.org> wrote:
>
> Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment:
>
> Could anybody please make a review? This is just a first step, we need to
> do it before making other steps: implementing more modern import API,
> supporting large ZIP files and ZIP files with comments, implementing
> loading binary extensions from ZIP files, etc.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue25711>
> _______________________________________
>

Fixed issues on Windows.

I think Serhiy's PR is basically done, so now the question is do we want to merge it in and drop the C code? ;)
I obviously say yes because this is I/O-bound code and so the switch shouldn't be enough of a performance hit to warrant blocking the gain in maintainability long-term (especially if we try to clean the module up slowly).
Barry, since I know you work with zip files a lot at work did you want to check to make sure perf won't be an issue for your use-case?

Not sure if I'll have time before the core sprints to check the implementation with shiv, but I can give it a try then. Do you mind waiting until then?

I'm personally in no rush and I assume Serhiy isn't either with 3.8 cut-off quite a ways out, so I see no rush.

New changeset 79d1c2e6c9d1bc1cf41ec3041801ca1a2b9a995b by Serhiy Storchaka in branch 'master':
bpo-25711: Rewrite zipimport in pure Python. (GH-6809)
https://github.com/python/cpython/commit/79d1c2e6c9d1bc1cf41ec3041801ca1a2b9a995b

New changeset 9da3961f364da2a3ced740230b85ffb4309238d3 by Serhiy Storchaka in branch 'master':
bpo-25711: Move _ZipImportResourceReader from importlib to zipimport. (GH-9406)
https://github.com/python/cpython/commit/9da3961f364da2a3ced740230b85ffb4309238d3

New changeset b2984ab9a7c458f8b7ed8978c0c95b109116895d by Serhiy Storchaka in branch 'master':
bpo-25711: Remove outdated zipimport tests. (GH-9404)
https://github.com/python/cpython/commit/b2984ab9a7c458f8b7ed8978c0c95b109116895d

Noticed this was still open when reviewing Elvis's zipimport patch for issue 34022.
Given the Python implementation has been merged, should we close this as resolved, and open new issues for any further changes (performance or otherwise)?