Prevent auto-deletion of `NamedTemporaryFile` after construction

[calestyo]

Feature or enhancement

Proposal:

Hey.

Using the the automatic cleanup of NamedTemporaryFile simplifies handling of the created temporary files obviously a lot.

There are however use cases, where sometimes it may be found after the named temp file has been created, that it actually shouldn’t be temporary but kept and maybe even moved to another name.

Consider that you want to update a local file from a downloaded source. You may first want to download from the remote location to some temporary file, then diff the two, and only if there are some differences, move the file to the local one (thereby overwriting that) and then do some extra processing of it.

Right now, there seems no documented/stable way of doing this:

• currently it seems to work by just moving the temporary file to another location... but a future version may do something like unlinkat() and delete the file using an open FD.
• One can set k._closer.delete = False but that is of course also not part of the public API.

I think it would be nice to have these properties exported under some proper public name or - at least documented to be part of the usable API, despite the underscore.

Thanks,
Chris.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[picnixz]

I don't think it's a common usecase and I think the user should be responsible at construction time for that. In the first place I don't think an automatically managed temporary file should be made if it can become a non-temporary one later.

For that, I'd suggest opening a DPO thread first.

[serhiy-storchaka]

This was proposed multiple times in the past, but it cannot be reliably implemented. One reason -- if the file was created with flag O_TEMPORARY, it will be deleted after closing by the OS.

This use case is resolved by using TemporaryDirectory and creating a file in a temporary directory. If you decided to keep the file, you can simply move it outside of the temporary directory.

[calestyo]

I don't think it's a common usecase

Sure? I mean that's effectively what many programs (like vi) do when they save an "edited" file.
They first write a "temporary" copy and then move it (atomically) over to the old filename.

Now you may of course argue that in this case the auto-managed file would be simply not appropriate, but it feels quite handy for clean up in case of an error.

This was proposed multiple times in the past, but it cannot be reliably implemented. One reason -- if the file was created with flag O_TEMPORARY, it will be deleted after closing by the OS.

Which is why I explicitly named NamedTemporaryFile, for which O_TEMPORARY should never be used, right?

This use case is resolved by using TemporaryDirectory and creating a file in a temporary directory. If you decided to keep the file, you can simply move it outside of the temporary directory.

Well, not really solved, because one is then back to manually ensuring the cleanup - which is of course possible.

But even if you say it should not be supported, it might make sense to add a sentence which tells that just moving the (temporary) file to another location - while effectively working right now, is not guaranteed to do so.

[ryan-duve]

Hey @calestyo -- if you end up opening a discussion at https://discuss.python.org/new, please link here. I'm interested in following the discussion.

[serhiy-storchaka]

Closing this issue as a duplicate of #67943.

[calestyo]

if you end up opening a discussion at https://discuss.python.org/new, please link here. I'm interested in following the discussion.

Not sure whether there'd be a lot to discuss?!

I mean the use case(s) are rather obvious, the implementation seems straightforward as it would be just exporting the already existing property via some API.

It’s been proposed[0] since 10 years, so I guess it's simply not desired (which I do not mean in a provocative way - I'm fully aware that one needs to keep the API clean and often it's just a matter of preference what one thinks is worth to have or not).

But you can of course open such discussion yourself. :-)

Thanks,
Chris.

[0] Sorry that I haven't found the duplicate, I was only searching for delete_on_close.