[Python-Dev] Destructors and Closing of File Objects

Guido van Rossum guido at python.org
Sat Apr 27 05:20:04 CEST 2013

There are no guarantees in life. On the other hand: Don't worry, be happy.

On Fri, Apr 26, 2013 at 7:39 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:
> Guido van Rossum <guido at python.org> writes:
>> On Monday, April 15, 2013, Nikolaus Rath wrote:
>>> Brian Curtin <brian at python.org <javascript:;>> writes:
>>> > On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath <Nikolaus at rath.org<javascript:;>>
>>> wrote:
>>> >> [ Note: I already asked this on
>>> >> http://stackoverflow.com/questions/15917502 but didn't get any
>>> >> satisfactory answers]
>>> >
>>> > Sorry, but that's not a reason to repost your question to this list.
>>> > If you have to ask somewhere else, it would be python-list, aka,
>>> > comp.lang.python.
>>> I figured it belonged here because the question is really about the
>>> internal implementation of file objects, which to me didn't seem like a
>>> question about using Python. But I'll give it a few days and send
>>> another mail there if still haven't found the answer by then.
>> You got your answer 16 hours ago on S.O.
> I guess you are referring to http://stackoverflow.com/a/15968516/293003
> from Armin Ringo?
> ,----
> | On Windows, NamedTemporaryFile uses a Windows-specific extension
> | (os.O_TEMPORARY) to ensure that the file is deleted when it is closed.
> | This probably also works if the process is killed in any way. However
> | there is no obvious equivalent on POSIX, most likely because on POSIX
> | you can simply delete files that are still in use; it only deletes the
> | name, and the file's content is only removed after it is closed (in any
> | way). But indeed assuming that we want the file name to persist until
> | the file is closed, like with NamedTemporaryFile, then we need "magic".
> |
> | We cannot use the same magic as for flushing buffered files. What occurs
> | there is that the C library handles it (in Python 2): the files are FILE
> | objects in C, and the C guarantees that they are flushed on normal
> | program exit (but not if the process is killed). In the case of Python
> | 3, there is custom C code to achieve the same effect. But it's specific
> | to this use case, not anything directly reusable.
> [...]
> `----
> It's indeed very informative, but it doesn't fully address the question
> because of the _pyio module which certainly can't use any custom C code.
> Does that mean that when I'm using x = _pyio.BufferedWriter(), I could loose
> data in the write buffer when the interpreter exits without me calling
> x.close(), but when using x = io.BufferedWriter(), the buffer is
> guaranteed to get flushed?
> (Note: this isn't a complaint, just curiosity about the Python
> internals).
> Best,
>    -Nikolaus
> --
>  »Time flies like an arrow, fruit flies like a Banana.«
>   PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list