[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Nick Coghlan report at bugs.python.org
Fri Feb 24 02:04:09 EST 2017


Nick Coghlan added the comment:

John, your problem sounds different - if you're opening the files in binary mode, then you'll be getting a default buffer that's probably 4k or 8k in size, so if you're writing less content than that, the subprocess won't see anything until you explicitly flush() the buffer to disk (and even if you're writing more than that, the subprocess may see a truncated version without an explicit flush()). 

By contrast, the issue here relates to the fact that on Windows it's currently necessary to do the following in order to get multiple handles to a NamedTemporaryFile:

1. Open the file in the current process
2. Write content to the file
3*. Close the file in the current process
4. Open the file by name in another process (or the current process)
5. Read content from the file
6. Close the second file handle
7*. Delete the file

*On POSIX systems, you can just skip step 3 and leave closing the original file handle until step 7, and that's the design that the current NamedTemporaryFile is built around. Most of the discussion above is about figuring out how to make that same approach "just work" on Windows (perhaps with some additional flags used in step 4), rather than  providing a third option beyond the current delete-on-close and delete-manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14243>
_______________________________________


More information about the Python-bugs-list mailing list