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.

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.

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.

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.

Closing this issue as a duplicate of #67943.

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.