Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'subject:: [': 0.03; 'behave': 0.07; 'constructor': 0.07; '21,': 0.09; 'attribute': 0.09; 'cleaned': 0.09; 'file-like': 0.09; 'api': 0.11; 'am,': 0.13; 'subject:] ': 0.14; 'wrote:': 0.15; '-tkc': 0.16; 'boolean': 0.16; 'exposes': 0.16; 'from:addr:python.list': 0.16; 'from:addr:tim.thechases.com': 0.16; 'from:name:tim chase': 0.16; 'message-id:@tim.thechases.com': 0.16; 'mismatching': 0.16; 'rantingrick': 0.16; 'received:70.251': 0.16; 'received:dsl.rcsntx.swbell.net': 0.16; 'received:rcsntx.swbell.net': 0.16; 'received:swbell.net': 0.16; 'stringio': 0.16; 'subject:between': 0.16; 'tarfile': 0.16; 'zipfile': 0.16; 'object,': 0.16; 'to:2**1': 0.21; 'header:In- Reply-To:1': 0.22; 'objects': 0.28; 'thu,': 0.28; 'object': 0.30; 'cases': 0.32; 'productive': 0.32; 'it.': 0.33; 'usually': 0.33; "i've": 0.33; 'to:addr:python-list': 0.34; 'instead': 0.34; 'header:User-Agent:1': 0.34; 'there': 0.34; 'supposed': 0.35; 'file': 0.36; 'passed': 0.37; 'could': 0.37; 'using': 0.37; 'should': 0.39; 'to:addr:python.org': 0.39; 'missing': 0.40; 'where': 0.40; 'prove': 0.64; 'to:charset:iso-8859-1': 0.82; '"foo"': 0.84 Date: Fri, 22 Jul 2011 06:25:36 -0500 From: Tim Chase User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Lars_Gust=E4bel?= , python-list@python.org Subject: Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs References: <5fd8e664-c855-41a2-9d8b-36d4c486f0b9@n35g2000yqf.googlegroups.com> <20110722082611.GB3575@axis.g33x.de> In-Reply-To: <20110722082611.GB3575@axis.g33x.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - boston.accountservergroup.com X-AntiAbuse: Original Domain - python.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tim.thechases.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 26 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1311333956 news.xs4all.nl 23838 [2001:888:2000:d::a6]:47182 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:10096 On 07/22/2011 03:26 AM, Lars Gustäbel wrote: > On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote: >> Tarfile is missing the attribute "fp" and instead exposes a >> boolean "closed". This mismatching API is asinine! Both >> tarfile and zipfile should behave EXACTLY like file objects > > What do you prove when you say that tarfile has no "fp" > attribute? You're not supposed to use the tarfile's internal > file object, there is nothing productive you could do with > it. While I've needed access to such a fp object, it's been limited to cases where I passed a file-like object to the constructor instead of a path-name: tf = tarfile.open(fileobj=foo, ...) so I had access to "foo" without reaching into the tarfile/zipfile object for the internal fp. Usually this involves using a StringIO object or a temp-file that then gets cleaned up when complete. -tkc