There's a lot of technical discussion of implementation details here, but not much about use cases. IMO, what's more important is whether NamedTemporaryFile is *useful* to people, and what they want to use it *for*. Working out how to implement it can come after we know what people want it to do.

My particular use case is actually pretty simple, and I suspect constitutes a fairly major proportion of what people want of this API:

1. Create a temporary file.
2. Write some data into it.
3. At some point, we're done writing to the file.
4. Only after that point, pass the name of the file to "somewhere else" for processing. That's often, in my use cases, as an argument to a subprocess.
5. Once we're all done, clean up securely.

The key additional requirement is that this is done "safely" (by which I mean I don't have to think about race conditions, etc, as someone else has that covered). What I think that means is that we need to maintain an open filehandle of *some* sort continually, but there's a point where the user can say "I'm done writing, I want to share this now".

Is there an actual known use case for the behaviour of deleting the file on close *rather* than at the end of the CM's scope? That's unlike any other CM I know of, where the scope ending is what triggers tidy-up.

Maybe NamedTemporaryFile should be retained for backward compatibility, but as a normal function, with the CM behaviour deprecated. It would still be essentially useless on Windows, but we maybe don't care about that.

In addition, we create a *new* context manager, that simply creates the file at the start and deletes it at close of scope. It returns a writeable file object, but that can be closed (and the documentation notes that for portability it *must* be closed before passing the name to another process for use).

I don't know enough about how we protect this against race condition attacks, but I'm pretty sure that this API gives us the best chance we're likely to have of doing so in a cross-platform manner. (Maybe we have a "reopen" method rather than "close". Or can we open *two* file handles at the start, one for writing and one for reading, return the one for writing, and keep the one for reading internal, purely to keep the file locked? I feel like that wouldn't work because if *we* can open a write handle, so could an attacker - but as I say, I'm not an expert).

Basically, I may be wrong, but I feel that we should stop trying to "rescue" NamedTemporaryFile, and instead try providing an *alternative* that handles the cross-platform use case that started all of this.