Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed6.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; 'bug': 0.02; '2.7': 0.04; '3.2': 0.05; 'url:bugs': 0.05; 'bug.': 0.07; 'raises': 0.07; 'received:verizon.net': 0.07; 'terry': 0.07; 'python': 0.08; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:80.91.229.12': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'received:lo.gmane.org': 0.09; 'subject:string': 0.09; 'am,': 0.12; '(ie,': 0.16; 'build?': 0.16; 'inherited': 0.16; 'ioerror': 0.16; 'narrow': 0.16; 'nonzero': 0.16; 'reedy': 0.16; 'stringio': 0.16; 'question.': 0.16; 'wrote:': 0.16; 'jan': 0.19; 'header:In-Reply-To:1': 0.22; 'worst': 0.23; 'suspect': 0.24; 'code': 0.25; 'string': 0.26; 'problem': 0.28; 'import': 0.28; 'unicode': 0.29; 'fixed': 0.29; 'do.': 0.30; '(depending': 0.30; 'useless': 0.30; 'error': 0.32; 'version': 0.32; 'typically': 0.32; 'does': 0.32; "can't": 0.33; 'there': 0.33; 'to:addr:python-list': 0.33; 'wondering': 0.33; 'someone': 0.34; 'header:User-Agent:1': 0.34; 'be.': 0.34; 'fail': 0.34; 'curious': 0.34; 'doc': 0.34; 'surprised': 0.34; 'header:X -Complaints-To:1': 0.35; 'post': 0.36; 'url:python': 0.36; '(from': 0.37; 'limitation': 0.37; 'but': 0.37; 'could': 0.38; 'received:org': 0.38; 'somewhat': 0.38; 'url:org': 0.38; 'should': 0.38; 'subject:: ': 0.39; 'characters': 0.39; 'ok,': 0.39; 'header :Mime-Version:1': 0.39; 'absolute': 0.39; 'why': 0.39; 'to:addr:python.org': 0.39; 'wide': 0.63; 'opened': 0.64; 'challenge': 0.66; 'making': 0.67; 'verified': 0.73; 'minimum,': 0.84; 'so:': 0.84; 'start)': 0.84 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Terry Reedy Subject: Re: Relative seeks on string IO Date: Tue, 06 Sep 2011 16:49:19 -0400 References: <48a795dc-992f-4665-9ada-60b2807fc3b8@u19g2000vbm.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gmane-NNTP-Posting-Host: pool-74-109-121-73.phlapa.fios.verizon.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 In-Reply-To: <48a795dc-992f-4665-9ada-60b2807fc3b8@u19g2000vbm.googlegroups.com> 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: 56 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1315342227 news.xs4all.nl 2467 [2001:888:2000:d::a6]:59199 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:12849 On 9/6/2011 3:18 AM, Pierre Quentel wrote: > I am wondering why relative seeks fail on string IO in Python 3.2 Good question. > from io import StringIO > txt = StringIO('Favourite Worst Nightmare') > txt.seek(8) # no problem with absolute seek Please post code without non-code indents, like so: from io import StringIO txt = StringIO('Favourite Worst Nightmare') txt.seek(8,0) # no problem with absolute seek txt.seek(0,1) # 0 characters from current position ok, and useless txt.seek(-2,2) # end-relative gives error message for cur-relative so someone can copy and paste without deleting indents. I verified with 3.2.2 on Win7. I am curious what 2.7 and 3.1 do. What system are you using? Does it have a narrow or wide unicode build? (IE, what is the value of sys.maxunicode?) > txt.seek(2,1) # 2 characters from current position > > raises "IOError: Can't do nonzero cur-relative seeks" (tested with > Python3.2.2 on WindowsXP) > > A seek relative to the end of the string IO raises the same IOError > Is there any reason why relative seeks on string IO are not allowed in > Python3.2, or is it a bug that could be fixed in a next version ? Since StringIO seeks by fixed-size code units (depending on the build), making seeking from the current position and end trivial, I consider this a behavior bug. At minimum, it is a doc bug. I opened http://bugs.python.org/issue12922 As noted there, I suspect the limitation in inherited from TextIOBase. But I challenge that it should be. I was somewhat surprised that seeking (from the start) is not limited to the existing text. Seeking past the end fills in with nulls. (They are typically a nuisance though.) from io import StringIO txt = StringIO('0123456789') txt.seek(15,0) # no problem with absolute seek txt.write('xxx') s = txt.getvalue() print(ord(s[12])) # 0 -- Terry Jan Reedy