python file API

[Dennis Lee Bieber]

Am 24.09.2012 23:49, schrieb Dave Angel:

Negative indices.

Which still doesn't handle the third seek mode -- relative to
current position.

I don't think I've ever written code to seek from the end of a file
-- but moving /x/-bytes from where the file currently is makes more
sense... For example, implementing chunked reading of a text file;
instead of handling a dangling partial line by holding it and appending
the next chunked read, one could use string methods to find the offset
of the last new-line marker relative to the length of the chunk and do a
relative seek backwards to position the next chunk at the start of that
partial line.

 

[Ian Kelly]

Am 25.09.2012 00:37 schrieb Ian Kelly:


But this is not a "real int", it has a special use. So I don't think it is
absolutely required to behave like an int.

The point of the proposal was to simplify the API. With that in mind,
if it's supposed to look like an int, then it should *be* an int.

 

[Thomas Rachel]

Am 25.09.2012 10:13 schrieb Dennis Lee Bieber:
Umpfzg. s/bit 7/bit 4/.

I don't think I'd want to work with any device where 0x10 (00010000
binary) modifies bit SEVEN. 0x40, OTOH, would fit my mental impression
of bit 7.

Of course. My fault.

It can as well be a bit mask, with OUTTGL = 0x11 toggling bit 4 and bit
0. Very handy sometimes.


Thomas

 

[Mark Lawrence]

Something along these lines http://docs.python.org/dev/**
whatsnew/3.3.html#pep-3151-**reworking-the-os-and-io-**exception-hierarchy<http://docs.python.org/dev/whatsnew/3.3.html#pep-3151-reworking-the-os-and-io-exception-hierarchy>?

I just tried to find out what error would be raised by seeking on a file
that doesn't support seeking and II think it's just OSError in the reworked
hierarchy. The error in Python 2.7 is

Traceback (most recent call last):
File "tmp.py", line 2, in <module>
sys.stdin.seek(5)
IOError: [Errno 29] Illegal seek

This corresponds to ESPIPE from errno.h which isn't referred to anywhere in
pip 3151:
http://www.python.org/dev/peps/pep-3151/

So I guess it would still need to be

try:
f.pos = 256
except OSError as e:
if e.errno != 29:
raise
print('Unseekable file')

Oscar

The thing I was thinking of is actually in the thread "syntax to
continue into the next subsequent except block" over on Python ideas.

 

[Grant Edwards]

Which still doesn't handle the third seek mode -- relative to
current position.

fileobj.pos += <whatever>

 

[Dennis Lee Bieber]

f.pos += delta

That's the only part of the proposal that I really think is an improvement
over the current method:

f.seek(delta, 1)

I actually had to google the whence code for relative seeking which I
wouldn't need to do if it were more descriptive.

But then I never do relative seeking. I'm pretty sure my programs have
always either read the whole file in order with no seeking or used random
access with absolute seeking.

Okay, I was a bit blind this morning...

And with the effective demise of tape-drives there's probably not
much difference. I could visualize where the seek mode was part of the
information passed down to a tape drive, making a "seek.current" much
faster than a "seek.set".

f.pos += delta

would be a "seek.set" and with a naive driver might trigger a rewind to
the start of the tape followed by a seek to the absolute position,
whereas the seek from current location would only move the tape by the
specified amount...

 

[Chris Angelico]

f.pos += delta

would be a "seek.set" and with a naive driver might trigger a rewind to
the start of the tape followed by a seek to the absolute position,
whereas the seek from current location would only move the tape by the
specified amount...

But a smart driver should always optimize the absolute seek to a
relative seek, unless there's a hard difference between them. After
all, the standard "read-ahead" technique is going to do an absolute
seek:

opaque_value = f.tell()
f.read(blah blah blah)
f.seek(opaque_value)

ChrisA

 

[Thomas Rachel]

Am 25.09.2012 09:28 schrieb Steven D'Aprano:

On the contrary, since the pos attribute is just a wrapper around seek,
you can seek beyond EOF easily:

f.pos = None
f.pos += 10

Yes, from a syscall perspective, it is different: it is a tell()
combined with a seek set instead of a relative seek. As someone
mentionned, e. g. in the case of a streamer tape this might make a big
difference.

But for anything but the most trivial usage, I would recommend sticking
to the seek method.

ACK. This should be kept as a fallback.

... or we need multiple attributes, one for each mode ...

Yes. That's what I would favourize: 3 attributes which each take a value
to be passed to seek.

So all up, I'm -1 on trying to replace the tell/seek API, and -0 on
adding a second, redundant API.

ACK.


Thomas

 

[Ramchandra Apte]

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






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

+1