execute the attached script. It should return

FileExistsError: [Errno 17] File exists: 'a_link' -> 'a'

but it returns

FileExistsError: [Errno 17] File exists: 'a' -> 'a_link'

I concur the current message is misleading.

OSError makes the string "file1 -> file2". This also affects other methods calling `path_error2()` such as os.link().

I've been investigating this issue and did not come up with some easy solution.

So the problem is:
os_symlink uses `path_error2` to throw exception.
the order of file arguments now is src then dest. For provided example src is `a` and dest is `sym_link`. As a result `src` -> `dest` is generated here https://github.com/python/cpython/blob/master/Objects/exceptions.c#L1059

If we change order of arguments passed to `path_error2`, error message will be generated properly but OSError.filename will be incorrect (a_link instead of a) and following test will fail for `link`/`symlink`

https://github.com/python/cpython/blob/master/Lib/test/test_os.py#L2901

Not sure if it's OK or not, so it definitely needs some input from Python core developers.

The current error message looks good to me. What is wrong with it?

A symbolic link is typically represented the other way around, from the point of view of the link pointing at the target. However, Python conceptualizes linking as something like a copy or rename operation, with source and destination filenames, and the current error message represents this point of view.

This is not about how a symbolic link is represented. This is about how the operation of creating a symbolic link is represented. The first filename is the first argument of os.symlink(), the second filename is the second argument. Try to run

    os.symlink('a', 'a_link')
    os.symlink('b', 'a_link')

You should get an error:

    FileExistsError: [Errno 17] File exists: 'b' -> 'a_link'

To me the error message is in the model of a source -> destination operation, in which the arrow indicates the operation's information flow (e.g. of the target path or inode number) from the source file to the destination file. I've never viewed it superficially as just an ordering of parameter1 -> parameter2.

I agree with Eryk. The error message is misleading. When I see it, I take it as source -> destination. I think we should make the error message clearer, or document it in the OSError documentation.

See issue20517 for the discussion about current implementation. Are there any ideas about clearer error messages?

Added Larry as the author of the original idea and implementation.

"Special cases aren't special enough to break the rules."  I want the error message to mirror the API, which it currently does.  If we swapped them, the error message would now contradict the API.  So no, I don't support swapping "src" and "dst" in the error message only when the error pertains to os.symlink.

If literally every time the two-filename version of OSError is used inside Python, the two filenames are "src" and "dst", then we could consider making it slightly more explicit, e.g.

    FileExistsError: [Errno 17] File exists: src='a', dst='a_link'

I think I'd want the source code to reflect this (e.g. thinking about "src" and "dst" rather than "filename" and "filename2").

Would OP et al consider this change to the error message an improvement, or is it not interesting?

@Larry - that would be an acceptable solution!

I'm here because I encountered this error independently. I explain why the  arrow is a problem here: https://bugs.python.org/issue35367

The issue is that the '->' notation is already used by the standard operating system utilities in this context, so for Python overload this semantically in this case is the source of all the confusion.

It would avoid the scare that we've all encountered if it just said 'src'/'dst' rather than '->'.

Thanks!
R

Just reached this issue independently (spent a few minutes debugging an error message like "FileExistsError: [Errno 17] File exists: 'a' -> 'b'", where 'a' didn't exist...)

I agree with Rich on this - for me, the source of confusion was that the way Python uses the arrow notation is just swapped from how ls(1) uses it.

Stage is "patch review" but I couldn't find any PR for it; if we're good with Larry's solution then I'm happy to post a PR implementing it.