Jay Chu <tothes...@gmail.com> added the comment: For me, and as you've pointed out, the current doc of `Path.link_to` is already wrong and misleading. Perhaps a fix of the doc should be made as a first step.
The doc uses the expression "Create a hard link pointing to a path named target." But comparing this to the doc of `Path.symlink_to`, which says "Make this path a symbolic link to target.", (and the doc of `os.link`, which says, "Create a hard link pointing to src named dst.",) the current doc should actually be "Create a hard link at `target` pointing to this path." Sadly the argument name can't be changed here already. And the doc of `Path.symlink_to` even have a helpful note: "Note: The order of arguments (link, target) is the reverse of os.symlink()’s." We could also add one for `Path.link_to`, too, like "Note: The order of arguments (link, target) is the consistent with os.link()’s. Based on that foundation, we could finally continue to implement the correct "Path.hardlink_to". We can refer to how people retained `subprocess.call` while adding a newer , preferred `subprocess.run`, by noting people to prefer `Path.hardlink_to` as it's more consistent with the `pathlib` and OOP, along with telling them the obscurity of `Path.link_to` and why it's left here for backward capability. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39950> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
