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 <nikol...@rath.org> wrote: > Guido van Rossum <gu...@python.org> writes: >> On Monday, April 15, 2013, Nikolaus Rath wrote: >>> Brian Curtin <br...@python.org <javascript:;>> writes: >>> > On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath >>> > <nikol...@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@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com