Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > python file API

Reply
Thread Tools

python file API

 
 
zipher
Guest
Posts: n/a
 
      09-24-2012
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
 
Reply With Quote
 
 
 
 
Dave Angel
Guest
Posts: n/a
 
      09-24-2012
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

 
Reply With Quote
 
 
 
 
Chris Kaynor
Guest
Posts: n/a
 
      09-24-2012
On Mon, Sep 24, 2012 at 2:49 PM, Dave Angel <(E-Mail Removed)> 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.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-24-2012
On Tue, Sep 25, 2012 at 7:49 AM, Dave Angel <(E-Mail Removed)> 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
 
Reply With Quote
 
Dave Angel
Guest
Posts: n/a
 
      09-24-2012
(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 <(E-Mail Removed)> 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
 
Reply With Quote
 
zipher
Guest
Posts: n/a
 
      09-24-2012
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
 
Reply With Quote
 
zipher
Guest
Posts: n/a
 
      09-24-2012
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
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      09-24-2012
On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <(E-Mail Removed)> 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?
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      09-24-2012
On Tue, Sep 25, 2012 at 8:37 AM, Ian Kelly <(E-Mail Removed)> wrote:
> On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <(E-Mail Removed)> 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
 
Reply With Quote
 
Mark Lawrence
Guest
Posts: n/a
 
      09-24-2012
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to generate execute file that include enthought.traits.api ,enthought.traits.ui.api ? ray Python 1 06-04-2010 03:49 PM
no module api file after generating ruby core api Bob Lu Ruby 0 06-25-2009 03:07 AM
Profiling API or Membership API John123 ASP .Net 0 10-20-2006 03:18 PM
Calling the C API from Python and Python program from same C API -bidirectional Praveen, Tayal (IE10) Python 0 03-17-2005 06:33 AM
What API replaces the unlock API that existed in gcc 2.9.3? Shlomo Anglister C++ 1 08-02-2004 06:50 PM



Advertisments