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

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

Low level file descriptors and high-level Python files

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

Contents

  Low level file descriptors and high-level Python files Steven D'Aprano <steve@pearwood.info> - 2015-09-02 00:57 +1000
    Re: Low level file descriptors and high-level Python files random832@fastmail.us - 2015-09-01 11:56 -0400
    Re: Low level file descriptors and high-level Python files Laura Creighton <lac@openend.se> - 2015-09-01 19:41 +0200
      Re: Low level file descriptors and high-level Python files Grant Edwards <invalid@invalid.invalid> - 2015-09-01 22:19 +0000
        Re: Low level file descriptors and high-level Python files Laura Creighton <lac@openend.se> - 2015-09-02 09:02 +0200

#95832 — Low level file descriptors and high-level Python files

Let's suppose somebody passes me a file descriptor to work with. It could
come from somewhere else, but for the sake of discussion let's pretend I
create it myself this way:

import os
fd = os.open("some path", "w")


I then turn it into a file object:

file_obj = os.fdopen(fd, mode)


Q1:  In this example, I know that I opened the fd in write mode, because I
did it myself. But since I'm not actually opening it, how do I know what
mode to use in the call to fdopen? Is there something I can call to find
out what mode a file descriptor has been opened with?


Now let's suppose I solve that problem, process the file_obj, and close it:

file_obj.close()

Q2:  Do I still have to close the file descriptor with os.close(fd)? 
(I think not.)


Q3:  I could probably answer Q2 myself if I knew how to check whether a fd
was open or not. With a file object, I can inspect file_obj.closed and it
will tell me whether the file is open or not. Is there an equivalent for
file descriptors?



-- 
Steven

[toc] | [next] | [standalone]

#95835

On Tue, Sep 1, 2015, at 10:57, Steven D'Aprano wrote:
> Q1:  In this example, I know that I opened the fd in write mode, because
> I
> did it myself. But since I'm not actually opening it, how do I know what
> mode to use in the call to fdopen? Is there something I can call to find
> out what mode a file descriptor has been opened with?

In principle, you can find out with fcntl.

In practice, don't you already know what kind of processing you intend
to do with the file? If your "processing" involves writing, just try
writing to it, and if it doesn't work then it's the caller's fault for
passing in a read-only file handle.

> Now let's suppose I solve that problem, process the file_obj, and close
> it:
> 
> file_obj.close()
> 
> Q2:  Do I still have to close the file descriptor with os.close(fd)? 
> (I think not.)

You do not.

> Q3:  I could probably answer Q2 myself if I knew how to check whether a
> fd
> was open or not. With a file object, I can inspect file_obj.closed and it
> will tell me whether the file is open or not. Is there an equivalent for
> file descriptors?

Well, if you try to call os.close, or any other operation for that
matter, it will raise an OSError with errno=EBADF.

Note that if the file _has_ been closed it may be reused by the next
open call, so it's best not to use this test method in production code.

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

#95843

In a message of Wed, 02 Sep 2015 00:57:22 +1000, "Steven D'Aprano" writes:
>Let's suppose somebody passes me a file descriptor to work with. It could
>come from somewhere else, but for the sake of discussion let's pretend I
>create it myself this way:

>Q1:  In this example, I know that I opened the fd in write mode, because I
>did it myself. But since I'm not actually opening it, how do I know what
>mode to use in the call to fdopen? Is there something I can call to find
>out what mode a file descriptor has been opened with?

for POSIX things use fnclt.  YOu have to parese the bits yourself
and I always have to look that up to see what the grubby details
are.  No clue what you do on windows.

Don't go around closing things you don't know are open.  They
could be some other processes' thing.

Laura

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

#95848

On 2015-09-01, Laura Creighton <lac@openend.se> wrote:

> Don't go around closing things you don't know are open.  They
> could be some other processes' thing.

I don't understand.  Closing a file descriptor that isn't open is
harmless, isn't it?  Closing one that _is_ open only affects the
current process.  If other processes had the same fd open, it's still
open for them.

-- 
Grant Edwards               grant.b.edwards        Yow! FUN is never having to
                                  at               say you're SUSHI!!
                              gmail.com            

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

#95855

In a message of Tue, 01 Sep 2015 22:19:15 -0000, Grant Edwards writes:
>On 2015-09-01, Laura Creighton <lac@openend.se> wrote:
>
>> Don't go around closing things you don't know are open.  They
>> could be some other processes' thing.
>
>I don't understand.  Closing a file descriptor that isn't open is
>harmless, isn't it?  Closing one that _is_ open only affects the
>current process.  If other processes had the same fd open, it's still
>open for them.
>
>-- 
>Grant Edwards               grant.b.edwards        Yow! FUN is never having to
>                                  at               say you're SUSHI!!
>                              gmail.com            

This is me being tired and not saying things properly.  What I meant was
don't go around closing mkstemp files thinking you can reopen them later,
because in between the time you use mkstemp to make the file and you open
it up again later somebody else may have replaced that file.  Including
some other program running mkstemp which was desparate to make the exact same
filename you did.  But that's not what I said ... so thank you.

Laura

[toc] | [prev] | [standalone]

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

csiph-web