By default, when you create a new zipfile object to create a .zip archive with, it stores the data uncompressed.
Only noticed the issue when a 100MB zip file suddenly became 3MB after I had edited one of the files and re-saved the archive.
The reason for the default is probably that python can be built with none of zlib, bzip2 or lzma support:
> If ZIP_DEFLATED, ZIP_BZIP2 or ZIP_LZMA is specified but the corresponding module (zlib, bz2 or lzma) is not available, RuntimeError is raised.
in which case only STORED is available, therefore that's the only possible default, any other would lead to zipfile raising errors out of the box for some people.
It would probably have been a better idea to just not use a default, and require the compression method to always be specified, at least when opening zipfiles with modes other than "r".
I don't think that logic works. You can default to "deflate if available" just fine.
And I don’t even have to imagine it, because there’s an example right in the python builtins: open in text mode will use… whatever garbage `locale.getpreferredencoding()` returns. Fantastic way to create hard to reproduce bugs.
> An inconsistent and variable default would be significantly, unfathomably, worse than a "bad" default.
Even if you're right on that, I will still say that defaulting to no compression is significantly worse than going "error missing library" for people that have a partial install.
Text mode is perfectly good, it’s what users want in a good 90% of cases. Possibly more.
Compressing archives most only makes sense if you have some huge (many many millions of lines) set of source code because that's a lot of data, more than one file that you want to compress, and low entropy in those files. Only in that combination does zip with compression make sense over uncompressed archives or compression without archive format.
Of course, zip can shoehorn both functions that you usually don't need together into one format and we're usually not CPU-bound anyway so I totally see why you might as well always apply a small amount of compression, but I would beg to differ if you say "it's basically useless to have zip without compression support". There are more cases where zip with compression is completely redundant than cases where it helps you.
And how do you read those archives (or, for that matter, create them) using a ZIP library that doesn't know how to deal with compressed data?
My point is simply that DEFLATE support should be considered mandatory for any ZIP implementation. Without it, most archives you encounter will be unreadable. Yes, it can still handle archives which contain only STOREd files -- but that's an edge case which most archives won't fall into.
You don’t because you just want to archive them not read them.
> The compression method shall be either 0 (“stored”) or 8(“deflated”).
The format does not prescribe a compression algorithm (many could be available for use). It's merely a container.
[1] ISO/IEC WD 21320-1, Document Container File - Part 1: Core - https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39...