In issue14243 [1] there are two issues being tracked: - the difference in opening shared files between posix and Windows - the behavior of closing the underlying file in the middle of NamedTemporaryFile's context management I'd like to address and get feedback on the context management issue. ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp = open(fp.name()) data = fp.read() assert data == 'some_data' ``` Occasionally, it is desirable to close and reopen the temporary file in order to read the contents (there are OSes that cannot open a temp file for reading while it is still open for writing). This would look like: ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp.close() # Windows workaround fp.open() data = fp.read() assert data == 'some_data' ``` The problem is that, even though `fp.open()` is still inside the context manager, the `close()` call deletes the file [2]. To handle this scenario, my proposal is two-fold: 1) stop using the TEMPFILE OS attribute so the OS doesn't delete the file on close 2) add `.open()` to NamedTemporaryFile A possible side effect of (1) is that temp files may accumulate if the interpreter crashes, but given the file-management abilities in today's software that seems like a minor annoyance at most. The backwards compatibility issue of (1) is that the file is no longer deleted after a manual `close()` -- but why one would call close() and then stay inside the CM, outside of testing, I cannot fathom. [3] So, opinions on modifying NamedTemporaryFile to not delete on close() if inside a CM, and add open() ? -- ~Ethan~ [1] https://bugs.python.org/issue14243 [2] plus, the `.open()` doesn't yet exist [3] feel free to educate me :-)