> On 8 Apr 2021, at 22:31, Ethan Furman <et...@stoneleaf.us> wrote:
>
> 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.flush(). # needed to ensure data is actually in the file ;-)
> fp = open(fp.name())
> data = fp.read()
>
> assert data == 'some_data'
> ```
I generally use a slightly different pattern for this:
with NamedTemporaryFile() as fp:
fp.write(b'some data’)
fp.flush()
fp.seek(0)
data = fp.read()
That is, reuse the same “fp” and just reset the stream. An advantage of this
approach is that you don’t need a named temporary file for this (and could even
use a spooled one). That said, I at times use this pattern with a named
temporary file with a quick self-test for the file contents before handing of
the file name to an external proces.
>
> 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
I’ve never had the need for such an API, but must say that I barely use Windows
and hence have not run into the “cannot open file for reading what it is still
open for writing” issue.
>
> 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~
>
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LOE7BKIHV66IG3J6LP3UAJSZL65AXWCK/
Code of Conduct: http://python.org/psf/codeofconduct/
