[Python-ideas] Adding ziplib

[Ryan Gonzalez]

On Mon, Feb 16, 2015 at 5:32 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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?
>
>
This occurred to me a few moments ago. How about arclib?


> 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?
>
>
I'll look into that.


> 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
> <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/
>
> _______________________________________________
> 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/
>
>


-- 
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/06110563/attachment.html>