Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104929 > unrolled thread

Seekable files

Back to article view | Back to comp.lang.python

Contents

  Seekable files Steven D'Aprano <steve@pearwood.info> - 2016-03-15 21:35 +1100
    Re: Seekable files Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-15 10:49 +0000
      Re: Seekable files Marko Rauhamaa <marko@pacujo.net> - 2016-03-15 13:16 +0200
        Re: Seekable files Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-15 13:49 +0000
          Re: Seekable files Marko Rauhamaa <marko@pacujo.net> - 2016-03-15 16:26 +0200
            Re: Seekable files Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-15 14:25 +0000

#104929 — Seekable files

Suppose somebody passes me an open file handle. What's the right way to tell
if it is seekable in Python 2?

I see that stdin has a seek and tell method, but they raise:

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

Are seek and tell guaranteed to exist on all files?

Is there some other way to tell whether the file supports seeking other than
to try it and see?


(In Python 3, files have a seekable method.)


-- 
Steven

[toc] | [next] | [standalone]

#104931

On 2016-03-15, Steven D'Aprano <steve@pearwood.info> wrote:
> Suppose somebody passes me an open file handle. What's the right way to tell
> if it is seekable in Python 2?
>
> I see that stdin has a seek and tell method, but they raise:
>
> py> sys.stdin.tell()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> IOError: [Errno 29] Illegal seek
>
> Are seek and tell guaranteed to exist on all files?

Expecting strict object types isn't really how Python works - while
all subclasses of 'file' are guaranteed to have methods called 'seek'
and 'tell' (although they're not of course guaranteed to do anything
useful), most Python code that says it expects a 'file' doesn't really
mean it wants a subclass of 'file', it means it wants something that
provides a certain subset of the usual file-like methods.

So the answer to your question rather depends on what you mean by
"guaranteed to exist" and "all files". Even actual standard 'file'
objects, while having 'seek' and 'tell', may well just throw an
exception if you try and call those methods as the underlying
operating system file handle the object is attached to does not
support seeking.

> Is there some other way to tell whether the file supports seeking other than
> to try it and see?

No.

> (In Python 3, files have a seekable method.)

Yes, but all it is is a wrapper that does try-it-and-see for you.

I'd just do something like:

  try:
      fileobj.seek(where-i-want-to-seek-to)
  except (AttributeError, EnvironmentError):
      # file is not seekable

[toc] | [prev] | [next] | [standalone]

#104934

Jon Ribbens <jon+usenet@unequivocal.co.uk>:

> I'd just do something like:
>
>   try:
>       fileobj.seek(where-i-want-to-seek-to)
>   except (AttributeError, EnvironmentError):
>       # file is not seekable

Unlike Java, Python does not declare syntactically which exceptions the
caller should expect. Unfortunately, the library documentation is not
clear on it, either. So it is often a bit difficult to write proper
try-except logic around a function.

Having to specify the possible exceptions in Java is very painful and
has complicated the introduction of closures to Java quite a bit. I
think it points to a big practical problem in the whole exception
paradigm. Makes you wonder if the old error code mechanism would have
been better, after all. ("Why does Go not have exceptions?" <URL:
https://golang.org/doc/faq>.)


Marko

[toc] | [prev] | [next] | [standalone]

#104939

On 2016-03-15, Marko Rauhamaa <marko@pacujo.net> wrote:
> Jon Ribbens <jon+usenet@unequivocal.co.uk>:
>> I'd just do something like:
>>
>>   try:
>>       fileobj.seek(where-i-want-to-seek-to)
>>   except (AttributeError, EnvironmentError):
>>       # file is not seekable
>
> Unlike Java, Python does not declare syntactically which exceptions the
> caller should expect. Unfortunately, the library documentation is not
> clear on it, either. So it is often a bit difficult to write proper
> try-except logic around a function.

This is true, although I'm not sure why you are mentioning it here
since I'm fairly sure the above code suggestion is reasonably correct
and the documentation is pretty clear.

> Having to specify the possible exceptions in Java is very painful and
> has complicated the introduction of closures to Java quite a bit.

It is one of the extremely serious design errors in Java, I think.

> I think it points to a big practical problem in the whole exception
> paradigm.

Well, no. That one individual language screwed up its implementation
of exceptions does not mean the whole concept of exceptions is broken.

> Makes you wonder if the old error code mechanism would have
> been better, after all. ("Why does Go not have exceptions?" <URL:
> https://golang.org/doc/faq>.)

I think they are wrong, and indeed their argument seems to be a
ludicrous one based upon a misunderstanding of the English meaning of
the word "exception"!

Any high-level language that does not include exceptions is not fit
for purpose, in my opinion.

[toc] | [prev] | [next] | [standalone]

#104940

Jon Ribbens <jon+usenet@unequivocal.co.uk>:

> On 2016-03-15, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Having to specify the possible exceptions in Java is very painful and
>> has complicated the introduction of closures to Java quite a bit.
>
> It is one of the extremely serious design errors in Java, I think.
>
>> I think it points to a big practical problem in the whole exception
>> paradigm.
>
> Well, no. That one individual language screwed up its implementation
> of exceptions does not mean the whole concept of exceptions is broken.

Python and Java make two.

>> Makes you wonder if the old error code mechanism would have
>> been better, after all. ("Why does Go not have exceptions?" <URL:
>> https://golang.org/doc/faq>.)
>
> I think they are wrong, and indeed their argument seems to be a
> ludicrous one based upon a misunderstanding of the English meaning of
> the word "exception"!
>
> Any high-level language that does not include exceptions is not fit
> for purpose, in my opinion.

I reserve my judgement for now. However, let it be said that exceptions
are supposed to make the code flow better. Instead, they are often
making code awkward-looking and "bouncy."


Marko

[toc] | [prev] | [next] | [standalone]

#104941

On 2016-03-15, Marko Rauhamaa <marko@pacujo.net> wrote:
> Jon Ribbens <jon+usenet@unequivocal.co.uk>:
>> On 2016-03-15, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> I think it points to a big practical problem in the whole exception
>>> paradigm.
>>
>> Well, no. That one individual language screwed up its implementation
>> of exceptions does not mean the whole concept of exceptions is broken.
>
> Python and Java make two.

Except Python didn't screw up its implementation of exceptions at all.
That the documentation could be better doesn't make it "broken".

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web