Author escape0707
Recipients barneygale, escape0707
Date 2021-01-22.03:40:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1611286831.79.0.0509409096866.issue39950@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2021-01-22 03:40:31escape0707setrecipients: + escape0707, barneygale
2021-01-22 03:40:31escape0707setmessageid: <1611286831.79.0.0509409096866.issue39950@roundup.psfhosted.org>
2021-01-22 03:40:31escape0707linkissue39950 messages
2021-01-22 03:40:31escape0707create