<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 16, 2015 at 5:32 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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).</div><div><br></div><div>But why "ziplib"? Why not something generic like "archive" that doesn't sound like it's specific to ZIP files?</div><div><br></div></div></blockquote><div><br></div><div>This occurred to me a few moments ago. How about arclib?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>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?</div><div><br></div></div></blockquote><div><br></div><div>I'll look into that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Sent from a random iPhone</div><div><div class="h5"><div><br>On Feb 16, 2015, at 15:10, Ryan Gonzalez <<a href="mailto:rymg19@gmail.com" target="_blank">rymg19@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Python has support for several compression methods, which is great...sort of.</div><div><br></div><div>Recently, I had to port an application that used zips to use tar+gzip. It *sucked*. Why? Inconsistency.</div><div><br></div><div>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 <a href="http://bugs.python.org/issue22208" target="_blank">proposed on the bug tracker</a> but hasn't had any activity for a while.</div><div><br></div><div>Then, zipfile and tarfile's extract methods have slightly different arguments. Zipinfo has namelist, and tarfile as getnames. It's all a mess.</div><div><br></div><div>The idea is to reorganize Python's zip support just like the sha and md5 modules were put into the hashlib module. Name? ziplib.</div><div><br></div><div>It would have a few ABCs:</div><div><br></div><div>- an ArchiveFile class that ZipFile and TarFile would derive from.</div><div>- a BasicArchiveFile class that ArchiveFile extends. bz2, lzma, and (maybe) gzip would be derived from this one.</div><div>- ArchiveFileInfo, which ZipInfo and TarInfo would derive from. ArchiveFile and ArchiveFileInfo go hand-in-hand.</div><div><br></div><div>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.</div><div><br></div><div>I'm not quite sure how gzip fits into this, since it has a very minimal API.</div><div><br></div><div>Thoughts?</div><div><br></div>-- <br><div><div dir="ltr">Ryan<div><div>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."</div></div>Personal reality distortion fields are immune to contradictory evidence. - srean<div>Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a></div></div></div>
</div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Python-ideas mailing list</span><br><span><a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a></span><br><span><a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a></span><br><span>Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a></span></div></blockquote></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Ryan<div><div>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."</div></div>Personal reality distortion fields are immune to contradictory evidence. - srean<div>Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a></div></div></div>
</div></div>