<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 2, 2015 at 5:04 PM Rose Ames <<a href="mailto:rose@happyspork.com">rose@happyspork.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At pycon I talked with a few people about <a href="http://bugs.python.org/issue19699" target="_blank">bugs.python.org/issue19699</a>.<br>
The consensus seemed to be that zipimport wants a lot of work, possibly<br>
a rewrite.<br>
<br>
I'll have some time to work on this over the next couple of months, but<br>
I want to be working on the right thing.  Could the people who were<br>
involved in that conversation remind me of their concerns with<br>
zipimport?  What exactly would the goal of a rewrite be?<br></blockquote><div><br></div><div>I believe the participants consisted of Thomas Wouters, Greg Smith, Eric Snow, Nick Coghlan, and myself. In the end I think the general consensus for long-term maintenance was to write the minimal amount of code required that could read zip files and then write all of the import-related code on top of that. Basically the idea of freezing zipfile seemed messy since it has a ton of dependencies and baggage that simply isn't needed to replace zipimport.</div><div><br></div><div>I vaguely remember people suggesting writing the minimal zip reading code in C but I can't remember why since we have I/O access in importlib through _io and thus it's really just the pulling apart of the zip file to get at the files to import and thus should be doable in pure Python.<br></div></div></div>