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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
