Since Python 3.3 the zipfile module has support bzip2 and lzma compression, however the zipimporter does not support these. It would be awesome if zipimport did support them.

See also issue 17004 and issue 5950.

Zipimporter doesn't use zipfile (the former is written in C), so it unfortunately doesn't fall through for support.

Right, but it could still have support for those things implemented yea?

On Jun 13, 2014 7:39 PM, "Donald Stufft" <report@bugs.python.org> wrote:
>
>
> Donald Stufft added the comment:
>
> Right, but it could still have support for those things implemented yea?

Yes, it's just zipimport has a history of being difficult to maintain.

>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue21751>
> _______________________________________

As shown in msg180323, using lzma compression for typical *.py and *.pyc produces 8% less zip file, but reading from it is 2.5 times slower. The bzip2 compression is even worse. So there is no large benefit in supporting other compression methods.

I disagree that there is no large benefit. Python files aren't the only files that could exist inside of a zip file. Supporting LZMA import (or bz2) would make it easier to have LZMA or bzip2 wheels in the future without losing the ability to import them.

For non-Python files you don't need support of bzip2 or lzma compression in 
zipimport. Use zipfile which supports advanced compression.

I'm not sure what that statement means. There is package data that sits alongside python files. These cannot use anything but DEFLATED because zipimport doesn't support it.

related: issue #17630

Another use case is more aggressively shrinking the bundled copy of pip. We
don't really care about speed of execution there (since we only run it
directly once at install time to do the bootstrapping), but we do care
about the impact on the installer size.

However, that's a fairly specialised case - for wheel 2.0 in general, we
can consider dropping the "always usable as a sys.path entry" behaviour and
not need to worry about the constraints of zipimport (which has indeed
exhibited unfortunate "we touch it, we break it" behaviour in recent
releases, due to the vagaries of zip implementations on various platforms).

A more general archive importer written in Python could also be useful -
there's no requirement that all archive formats be handled by the existing
meta importer. Putting such an importer *after* the existing zip importer
in the metapath would minimise any risk of backwards incompatibility
issues, and allow it to initially be created as a third party module on
PyPI.

You can use deflate for Python files and advanced compression methods for large well-compressable package data.