[Python-ideas] shutil.symlink to allow non-race replacement of existing link targets

[Steven D'Aprano]

On Tue, May 14, 2019 at 10:37:57AM +0300, Serge Matveenko wrote:

> My point was that in case of `os.symlink` vs `shutil.symlink` it is
> not obvious how they are different even taking into account their
> namespaces.

Okay, but that's not what you said. I can't respond to what you meant to 
say in hindsight, only what you actually said at the time:

    I SEE AND EXPECT no obvious difference between `os.symlink` and 
    `shutil.symlink`.  [emphasis added]

Can we agree that the difference between os.symlink and shutils.symlink 
is visible (they are in different namespaces) and we should expect that 
they are different for that reason?

If we *can't* agree on that point, if you truly see no difference 
between (for example)

    os.open bz2.open gzip.open io.open etc.

then I don't think we will ever reach agreement. Our expectations are 
just too different.


I am happy to agree with you that the difference in qualified names is 
not enough to tell *how they differ*, only that they likely do differ. 
To know how they differ, one needs to read the docs, or ask.

I don't see this as a problem.


> In the case `os.remove` vs `list.remove` the difference is obvious as
> namespaces clearly represent different subjects. On the other hand, it
> is not that easy to guess the developer intent comparing `os` and
> `shutil` subjects.

There's no need to guess. The documentation is clear:

https://docs.python.org/3/library/os.html

    This module provides a portable way of using operating system 
    dependent functionality. [...] and for high-level file and directory 
    handling see the shutil module.


So I guess the question comes down to whether we believe that safely 
replacing an existing file with a symlink is low-level OS functionality 
or high-level functionality.

Here are three pieces of evidence to help decide:

(1) The Windows mklink command has no option to overwrite files: that 
suggests that on Windows, "make a syslink and overwrite the destination" 
is not low-level OS functionality.

(2) The Linux symlink system call does not override files either:

    man symlink

This also argues against putting this in the os module.

(3) The ``ln`` shell command does have an option to force overwriting. 
This argues in favour of treating it as a shell command and putting it 
in shutils.


In the rest of your email, you asked a bunch of questions. I assume that 
you intend them as rhetorical questions, but I don't know why you 
included them since they don't seem relevant. We could ask precisely the 
same questions no matter what we called this proposed function or where 
we put it.



-- 
Steven