Gregory P. Smith added the comment:
Based on our hallway pow-wow at PyCon 2015 sprints day #1... I audited the
zipfile module to confirm our suspicions about it being large.
In current Python 3.5 head's zipfile.py module here are the things it depends
directly upon from other modules:
Changes by Gregory P. Smith g...@krypto.org:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17630
___
Brett Cannon added the comment:
The more I think about this, the less useful it seems to be. We need zipimport
written in C for bootstrapping issues. If that's the case then time should be
put into making that work and not duplicating the functionality. I'm going to
leave this open but
Brett Cannon added the comment:
Re-positioning to work with both tarfile and zipfile since tarfile's 'r' will
transparently decompress as necessary. Might need to scale back some
functionality to make it easily work with both formats. But since are both
alternative storage solutions then some
