[Python-ideas] Adding ziplib

Ryan Gonzalez rymg19 at gmail.com
Tue Feb 17 00:10:48 CET 2015


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
<http://bugs.python.org/issue22208> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150216/e33cf25e/attachment.html>


More information about the Python-ideas mailing list