[Python-ideas] Adding ziplib

[Gregory P. Smith]

If bikeshedding about the name is all we're doing at this point I wouldn't
worry about the ancient BBS era .arc file format that nobody will write a
Python library to read. :)  I'd propose "archivers" as a module name,
though arclib is also nice.  If you want to really play homage to a good
little used archive format, call it arjlib. ;)

"The" problem with zipfile, and tarfile and similar today is that they are
all under maintained and have a variety of things inherent to the
underlying archive formats that are not common to all of them.  ie: zip
files have an end of archive central directory index.  tar files do not.
 rar files can be seen as a seemingly (sadly?) common successor to zip
files.  No doubt there are others (7z? cpio?).  zip files compress
individual files, tar files don't support compression as it is applied to
the whole archive after the fact.  The amount and type of directory
information available within each of these varies. And that doesn't even
touch multi file multi part archive support that some support for very
horrible hacky reasons.

coming up with common API for these with the key features needed by all is
interesting, doubly so for someone pedantic enough to get an implementation
of each correct, but it should be done as a third party library and should
ideally not use the stdlib zip or tar support at all. Do such libraries
exist for other languages? Any C++ that could be reused? Is there such a
thing as high quality code for this kind of task?

-gps

On Tue Feb 17 2015 at 1:05:04 PM Ryan Gonzalez <rymg19 at gmail.com> wrote:

> On Mon, Feb 16, 2015 at 10:20 PM, Florian Bruhin <me at the-compiler.org>
> wrote:
>
>> * Ryan Gonzalez <rymg19 at gmail.com> [2015-02-16 19:00:33 -0600]:
>> > 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?
>>
>> To me, that sounds like a library to handle ARC files:
>>
>> http://en.wikipedia.org/wiki/ARC_(file_format)
>>
>>
> Darn...
>
> Does anybody even use that format anymore?
>
>
>> Florian
>>
>> --
>> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>>          I love long mails! | http://email.is-not-s.ms/
>>
>> _______________________________________________
>> 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/
>  _______________________________________________
> 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/20150217/90ab7fb2/attachment-0001.html>