Serhiy Storchaka added the comment:
Yes, the current behavior is by design. It is consistent with the os.symlink(),
the "ln -s" command, and with any other way of creating symbolic links in other
programming languages.
--
resolution: -> not a bug
stage: -> resolved
status: open ->
SilentGhost added the comment:
Shannon, what you're suggesting is prone to the same issue (creating a broken
symlink) if a given destination does not exist relative to cwd. I think your
current solution is better as it explicitly provides the paths, but it's not
generalised enough to warrant
Shannon added the comment:
I can see how this change would be backward incompatible, however the current
behaviour seems inconsistent with the way pathlib functions otherwise. Within
two lines of code, the same path object can be pointing to two completely
different locations simply because
SilentGhost added the comment:
This would be backward incompatible change. I just wanted to point out that the
symlink was only broken because the file did not exist, and one might want to
legitimately create a link relative to the target's location. I'd imagine
creating a link in the same d
