Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5060D55C.3000407@davea.name>
References: <0ec1fe2e-890c-4e25-8047-4cb8bee0aa95@googlegroups.com> <5060D55C.3000407@davea.name>
Date: Tue, 25 Sep 2012 08:14:01 +1000
Subject: Re: python file API
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1222.1348524844.27098.python-list@python.org>
Lines: 33
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:29940

On Tue, Sep 25, 2012 at 7:49 AM, Dave Angel <d@davea.name> wrote:
> On 09/24/2012 05:35 PM, zipher wrote:
>> Let file-type have an attribute .pos for position.   Now you can get rid of the seek() and tell() methods and manipulate the file pointer more easily with standard arithmetic operations.
>>
>>>>> file.pos = x0ae1      #move file pointer to an absolute address
>>>>> file.pos +=1            #increment the file pointer one byte
>>>>> curr_pos = file.pos  #read current file pointer
>
> And what approach would you use for positioning relative to
> end-of-file?  That's currently done with an optional second parameter to
> seek() method.

Presumably the same way you reference a list element relative to
end-of-list: negative numbers. However, this starts to feel like magic
rather than attribute assignment - it's like manipulating the DOM in
JavaScript, you set an attribute and stuff happens. Sure it's legal,
but is it right? Also, it makes bounds checking awkward:

file.pos = 42 # Okay, you're at position 42
file.pos -= 10 # That should put you at position 32
foo = file.pos # Presumably foo is the integer 32
file.pos -= 100 # What should this do?
foo -= 100 # But this sets foo to the integer -68
file.pos = foo # And this would set the file pointer 68 bytes from end-of-file.

I don't see it making sense for "file.pos -= 100" to suddenly put you
near the end of the file; it should either cap and put you at position
0, or do what file.seek(-100,1) would do and throw an exception. But
doing the exact same operation on a saved snapshot of the position and
reassigning it would then have quite different semantics in an unusual
case, while still appearing identical in the normal case.

ChrisA