tempname.mktemp functionality deprecation

[Tim Chase]

On 2017-05-01 08:41, Cameron Simpson wrote:
> On 30Apr2017 06:52, Tim Chase <python.list at tim.thechases.com> wrote:
> >> > - use a GUID-named temp-file instead for less chance of
> >> > collision?
> 
> You could, but mktemp is supposed to robustly perform that task,
> versus "very very probably".

Though with the potential of its race-condition, mktemp() isn't a much
stronger guarantee.  A GUID seems like the best route.

> >> > - I happen to already have a hash of the file contents, so use
> >> >   the .hexdigest() string as the temp-file name?
> 
> Hashes collide. (Yes, I know that for your purposes we consider
> that they don't; I have a very similar situation of my own). And
> what if your process is running twice, or leaves around a previous
> temp file by accident (or interruption) _or_ the file tree contains
> filenames named after the hash of their content (not actually
> unheard of)?

In both case #1 (a *file* happens to have the name of the SHA256 hash,
but has different file contents) and case #2 (another process running
generates a *link* with the SHA256 of the matching content), the
os.link() should fail with the EEXISTS which I'm okay with.
Likewise, if there's an interruption, I'd rather have the stray
SHA-named link floating around than lose an existing file-name.

> What about some variation on:
> 
>   from tempfile import NamedTemporaryFile
>   ...
>   with NamedTemporaryFile(dir=your_target_directory) as T:
>       use T.name, and do your rename/unlink in here

As mentioned in my follow-up (which strangely your reply came in with
a References header referencing), the NamedTemporaryFile creates the
file on-disk, which means os.link(source, T.name) fails with the
EEXISTS.

-tkc