[Python-ideas] Adding ziplib (original) (raw)

Andrew Barnert abarnert at yahoo.com
Tue Feb 17 00:32:23 CET 2015

I love the idea (I've had to write my own custom wrapper around a subset of functionality for zip and tgz a few times, and I don't remember enjoying it...), and I especially like the idea of starting with the ABCs (which would hopefully encourage all those people writing cpio and 7z and whatever parsers to conform to the same API, even if they do so by wrapping LGPL libs like libarchive or even subprocessing out to command-line tools).

But why "ziplib"? Why not something generic like "archive" that doesn't sound like it's specific to ZIP files?

Also, this definitely seems like something that would be worth putting on PyPI first and then proposing for the stdlib. You're pretty much guaranteed to need a backport for 3.4 and 2.7 users anyway, right?

Sent from a random iPhone

On Feb 16, 2015, at 15:10, Ryan Gonzalez <rymg19 at gmail.com> wrote:

Python has support for several compression methods, which is great...sort of.

Recently, I had to port an application that used zips to use tar+gzip. It sucked. Why? Inconsistency. For instance, zipfile uses write to add files, tar uses add. Then, tar has addfile (which confusingly does not add a file), and zip has writestr, for which a tar alternative has been proposed on the bug tracker but hasn't had any activity for a while. Then, zipfile and tarfile's extract methods have slightly different arguments. Zipinfo has namelist, and tarfile as getnames. It's all a mess. The idea is to reorganize Python's zip support just like the sha and md5 modules were put into the hashlib module. Name? ziplib. It would have a few ABCs: - an ArchiveFile class that ZipFile and TarFile would derive from. - a BasicArchiveFile class that ArchiveFile extends. bz2, lzma, and (maybe) gzip would be derived from this one. - ArchiveFileInfo, which ZipInfo and TarInfo would derive from. ArchiveFile and ArchiveFileInfo go hand-in-hand. Now, the APIs would be more consistent. Of course, some have methods that others don't have, but the usage would be easier. zlib would be completely separate, since it has its own API and all. I'm not quite sure how gzip fits into this, since it has a very minimal API. Thoughts? -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/

Python-ideas mailing list Python-ideas at python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150216/a91ade2d/attachment.html>

More information about the Python-ideas mailing list