Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.freenet.ag!news2.euro.net!newsfeed.xs4all.nl!newsfeed4.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.038 X-Spam-Evidence: '*H*': 0.92; '*S*': 0.00; 'interpreter': 0.05; 'consistency': 0.09; 'issue:': 0.09; 'subject:question': 0.10; 'python': 0.11; 'times,': 0.14; 'behave': 0.16; 'closed,': 0.16; 'closed.': 0.16; 'flush': 0.16; 'itself,': 0.16; 'received:65.55.116.32': 0.16; 'received:65.55.116.7': 0.16; 'received:blu0-omc1-s21.blu0.hotmail.com': 0.16; 'underlying': 0.16; 'valueerror': 0.16; 'files.': 0.16; 'seems': 0.21; 'otherwise,': 0.22; 'to:name:python-list@python.org': 0.22; 'received:65.55.116': 0.24; 'mon,': 0.24; 'question': 0.24; 'certain': 0.27; 'gets': 0.27; 'header:In-Reply-To:1': 0.27; 'skip:- 40': 0.29; 'wondering': 0.29; 'url:bugs': 0.29; '[1]': 0.29; 'raise': 0.29; '[2]': 0.30; 'minor': 0.31; 'file': 0.32; 'url:python': 0.33; '(e.g.': 0.33; 'date:': 0.34; 'sense': 0.34; "i'd": 0.34; 'could': 0.34; 'skip:u 20': 0.35; 'case,': 0.35; 'but': 0.35; 'method': 0.36; 'hi,': 0.36; 'url:org': 0.36; 'so,': 0.37; 'email addr:python.org': 0.37; 'checks': 0.38; 'url:library': 0.38; 'to:addr:python-list': 0.38; 'rather': 0.38; 'subject:': 0.39; 'to:addr:python.org': 0.39; 'according': 0.40; 'most': 0.60; 'tell': 0.60; 'url:3': 0.61; 'email addr:gmail.com': 0.63; 'email name:python-list': 0.65; 'details': 0.65; 'here': 0.66; 'side': 0.67; 'close': 0.67; 'nobody': 0.68; 'default': 0.69; 'limit': 0.70; 'behavior': 0.77; 'bug!': 0.84; 'succeed.': 0.84; 'pipeline': 0.91; '2013': 0.98 X-TMN: [Wr9Sxf0uLWr1rpiNfuTAYVAGjzkhgYck] X-Originating-Email: [carlosnepomuceno@outlook.com] From: Carlos Nepomuceno To: "python-list@python.org" Subject: RE: Minor consistency question in io.IOBase Date: Tue, 28 May 2013 04:59:33 +0300 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 May 2013 01:59:33.0507 (UTC) FILETIME=[FFA38D30:01CE5B46] X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 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: 41 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1369706441 news.xs4all.nl 15894 [2001:888:2000:d::a6]:51191 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:46246 ----------------------------------------=0A= > Date: Mon=2C 27 May 2013 14:22:17 -0700=0A= > Subject: Minor consistency question in io.IOBase=0A= > From: dwight.guth@gmail.com=0A= > To: python-list@python.org=0A= >=0A= > Hi=2C so=2C I don't necessarily know if this is the right place to ask th= is question since it's kindof a rather technical one which gets into detail= s of the python interpreter itself=2C but I thought I'd start here and if n= obody knew the answer=2C they could let me know if it makes sense to ask on= python-dev.=0A= >=0A= > I am wondering why it is that the default implementations of certain of t= he "mixin" methods on IOBase seem to behave somewhat inconsistently. Specif= ically=2C the behavior of precisely when in the pipeline a method checks to= see whether the object is already closed seems to be inconsistent.=0A= >=0A= > In the following methods:=0A= >=0A= > IOBase.__next__=0A= > IOBase.readline=0A= > IOBase.tell=0A= >=0A= > In each case=2C these methods never check to see whether the file is clos= ed. __next__ immediately calls readline()=2C readline(limit) calls read(1) = at most limit times=2C and tell calls seek(0=2C 1). It is relying on the un= derlying method to raise a ValueError if the file is already closed. Otherw= ise=2C __next__ and readline will raise AttributeErrors on unreadable files= =2C and tell will raise an UnsupportedOperation on unseekable files. A side= effect of this is that readline(0) on a closed file will succeed.=0A= =0A= According to [1] & [2] it's a bug! Report the issue: http://bugs.python.org= /=0A= =0A= "close()=0A= Flush and close this stream. This method has no effect if the file is alrea= dy closed. Once the file is closed=2C any operation on the file (e.g. readi= ng or writing) will raise a ValueError."=0A= =0A= [1] http://docs.python.org/2/library/io.html#i-o-base-classes=0A= [2] http://docs.python.org/3.3/library/io.html#i-o-base-classes =