Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   python file API (http://www.velocityreviews.com/forums/t952628-python-file-api.html)

zipher 09-24-2012 09:35 PM

python file API
 
For some time now, I've wanted to suggest a better abstraction for the <file> type in Python. It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek(). But after attributes were introduced to Python, it seems it should be re-addressed.

Let file-type have an attribute .pos for position. Now you can get rid ofthe 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


You've now simplified the API by the removal of two obscure legacy methods and replaced them with a more basic one called "position".

Thoughts?

markj

Dave Angel 09-24-2012 09:49 PM

Re: python file API
 
On 09/24/2012 05:35 PM, zipher wrote:
> For some time now, I've wanted to suggest a better abstraction for the <file> type in Python. It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek(). But after attributes were introduced to Python, it seems it should be re-addressed.
>
> 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

> You've now simplified the API by the removal of two obscure legacy methods and replaced them with a more basic one called "position".
>
> Thoughts?
>
> markj


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.




--

DaveA


Chris Kaynor 09-24-2012 09:58 PM

Re: python file API
 
On Mon, Sep 24, 2012 at 2:49 PM, Dave Angel <d@davea.name> wrote:
>
> 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.
>


I'm not advocating for or against the idea, but that could be handled
the same way indexing into lists can index relative to the end:
negative indices.

Chris Angelico 09-24-2012 10:14 PM

Re: python file API
 
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

Dave Angel 09-24-2012 10:36 PM

Re: python file API
 
(forwarding to the list)

On 09/24/2012 06:23 PM, Mark Adam wrote:
> On Mon, Sep 24, 2012 at 4:49 PM, Dave Angel <d@davea.name> wrote:
>> On 09/24/2012 05:35 PM, zipher wrote:
>>> For some time now, I've wanted to suggest a better abstraction for the <file> type in Python. It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek(). But after attributes were introduced to Python, it seems it should be re-addressed.
>>>
>>> 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.

>
> As size is an oft-useful construct, let it (like .name) be part of the
> descriptor. Then
>
>>>> file.pos = file.size - 80 #80 chars from end-of-file

>
> (Or, one could make slices part of the API...)
>
> mark
>


Well, if one of the goals was to reduce the number of attributes, we're
now back to the original number of them.

--

DaveA

zipher 09-24-2012 10:36 PM

Re: python file API
 
You raise a valid point: that by abstracting the file pointer into a position attribute you risk "de-coupling" the conceptual link between the underlying file and your abstraction in the python interpreter, but I think the programmer can take responsibility for maintaining the abstraction.

The key possible fault will be whether you can trap (OS-level) exceptions when assigning to the pos attribute beyond the bounds of the actual file on the system...

markj

zipher 09-24-2012 10:36 PM

Re: python file API
 
You raise a valid point: that by abstracting the file pointer into a position attribute you risk "de-coupling" the conceptual link between the underlying file and your abstraction in the python interpreter, but I think the programmer can take responsibility for maintaining the abstraction.

The key possible fault will be whether you can trap (OS-level) exceptions when assigning to the pos attribute beyond the bounds of the actual file on the system...

markj

Ian Kelly 09-24-2012 10:37 PM

Re: python file API
 
On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <rosuav@gmail.com> wrote:
> 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?


Since ints are immutable, the language specifies that it should be the
equivalent of "file.pos = file.pos - 100", so it should set the file
pointer to 68 bytes before EOF.

> 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.


Which is the same result.

> 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.


I agree, but the language doesn't allow those semantics.

Also, what about the use of `f.seek(0, os.SEEK_END)` to seek to EOF?
I'm not certain what the use cases are, but a quick google reveals
that this does happen in real code. If a pos of 0 means BOF, and a
pos of -1 means 1 byte before EOF, then how do you seek to EOF without
knowing the file length?

Chris Angelico 09-24-2012 10:57 PM

Re: python file API
 
On Tue, Sep 25, 2012 at 8:37 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> 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?

>
> Since ints are immutable, the language specifies that it should be the
> equivalent of "file.pos = file.pos - 100", so it should set the file
> pointer to 68 bytes before EOF.


Oh, I forgot that guaranteed equivalency. Well, at least it removes
the ambiguity. I don't like it though.

ChrisA

Mark Lawrence 09-24-2012 11:12 PM

Re: python file API
 
On 24/09/2012 22:35, zipher wrote:
> For some time now, I've wanted to suggest a better abstraction for the <file> type in Python. It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek(). But after attributes were introduced to Python, it seems it should be re-addressed.
>
> 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

>
> You've now simplified the API by the removal of two obscure legacy methods and replaced them with a more basic one called "position".
>
> Thoughts?
>
> markj
>


This strikes me as being a case of if it ain't broke don't fix it.

--
Cheers.

Mark Lawrence.



All times are GMT. The time now is 03:08 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.