This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steven.daprano
Recipients docs@python, eric.smith, krey, steven.daprano
Date 2021-08-05.12:25:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20210805122429.GT10582@ando.pearwood.info>
In-reply-to <1628164831.71.0.0570542876067.issue44837@roundup.psfhosted.org>
Content
On Thu, Aug 05, 2021 at 12:00:31PM +0000, krey wrote:

> @steven.daprano My suggestion was changing the names of the args, not the order
> 
> Current
> def os.symlink(src, dst):
>     ln -s src dst

So far so good.

> Changing the names
> def os.symlink(dst, src):
>     ln -s dst src

That's not changing the names, that's changing the order.

You're putting the destination first, and the source second. That's the 
opposite order to that of `ln` in all the Unixes I can find, but it 
matches the order of Windows, which seems to be the only OS I can see 
that puts the destination (the path to the symlink) first and the source 
(the path to the target/original) second.

In any case, we have no power to change the order of arguments to `ln`.

> Changing the order
> def os.symlink(dst, src):
>     ln -s src dst

And that's just confused, because you have `ln` use the same order it 
has now, and symlink reverse the order.

> I concede that different unixes have different argnames for ln, it's a 
> bit of a mess. From a CS theory perspective, I think the GNU 
> convention makes more sense.

The GNU convention is the same convention as all the other Unixes, and 
os.symlink. Only the documented names are different.
History
Date User Action Args
2021-08-05 12:25:12steven.dapranosetrecipients: + steven.daprano, eric.smith, docs@python, krey
2021-08-05 12:25:12steven.dapranolinkissue44837 messages
2021-08-05 12:25:12steven.dapranocreate