Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!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; 'wed,': 0.03; 'subject:bug': 0.04; 'encoded': 0.05; 'mrab': 0.05; 'subject:Python': 0.06; 'bytes.': 0.07; 'mode,': 0.07; 'from:addr:python': 0.09; 'kelly': 0.09; 'undefined': 0.09; 'pm,': 0.10; '25,': 0.12; 'subject:file': 0.14; 'wrote:': 0.14; 'from:addr:mrabarnett.plus.com': 0.16; 'from:name:mrab': 0.16; 'message-id:@mrabarnett.plus.com': 0.16; 'received:84.92': 0.16; 'received:84.92.122': 0.16; 'received:84.92.122.60': 0.16; 'received:84.93': 0.16; 'received:84.93.230': 0.16; 'reply-to:addr :python-list': 0.16; 'meant': 0.18; 'bytes': 0.19; 'header:In- Reply-To:1': 0.21; 'values': 0.25; 'received:84': 0.25; 'position.': 0.29; 'unicode': 0.29; "won't": 0.30; 'value.': 0.32; 'file.': 0.32; 'does': 0.33; 'to:addr:python-list': 0.33; 'starting': 0.33; 'file': 0.34; 'header:User-Agent:1': 0.35; 'reply-to:addr:python.org': 0.35; 'sequence': 0.37; 'think': 0.38; 'subject:: ': 0.38; 'called': 0.39; 'attempt': 0.39; 'returned': 0.39; 'to:addr:python.org': 0.39; 'really': 0.40; 'results': 0.60; 'within': 0.60; 'subject:? ': 0.67; 'strange': 0.68; 'header :Reply-To:1': 0.72; 'reply-to:no real name:2**0': 0.72; 'subject:line': 0.73; '2:00': 0.84; 'presumably': 0.91 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4GAGp53U1UXebj/2dsb2JhbACYLo4EeMV9hhwElGaKUQ Date: Wed, 25 May 2011 22:52:39 +0100 From: MRAB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: python-list@python.org Subject: Re: Python 3.2 bug? Reading the last line of a file References: <3d81e2a0-6c86-4f12-a1c4-ce4c736172b6@y31g2000vbp.googlegroups.com> <4DDD5FD2.8040607@mrabarnett.plus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: python-list@python.org 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: 19 NNTP-Posting-Host: 82.94.164.166 X-Trace: 1306360361 news.xs4all.nl 49045 [::ffff:82.94.164.166]:47450 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6268 On 25/05/2011 21:54, Ian Kelly wrote: > On Wed, May 25, 2011 at 2:00 PM, MRAB wrote: >> You're opening the file in text mode, and seeking relative to the end >> of the file is not allowed in text mode, presumably because the file >> contents have to be decoded, and, in general, seeking to an arbitrary >> position within a sequence of encoded bytes can have undefined results >> when you attempt to decode to Unicode starting from that position. >> >> The strange thing is that you _are_ allowed to seek relative to the >> start of the file. > > I think that with text files seek() is only really meant to be called > with values returned from tell(), which may include the decoder state > in its return value. What do you mean by "may include the decoder state in its return value"? It does make sense that the values returned from tell() won't be in the middle of an encoded sequence of bytes.