[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

[Maor Kleinberger]

Maor Kleinberger <kmaork at gmail.com> added the comment:

> (Note: I consider all of these to be *extremely* obscure corner cases)
One bug was enough for me :)

> [Note there is no absolute() method - I assume you mean resolve()]
Of course there is an absolute() method, I'm not sure what you are saying...

> it seems to me that 'b:a' is "absolute-ish" (drive-relative)
I think that is incorrect. As written here: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#fully-qualified-vs-relative-paths, "If a file name begins with only a disk designator but not the backslash after the colon, it is interpreted as a relative path to the current directory on the drive with the specified letter."
In that case, WindowsPath('C:a').is_absolute() should return False, (as it does today) and WindowsPath('C:a').absolute() should return a path on drive C:, with 'a' joined with the working directory in drive C:.

> I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
I disagree with that as well. "./b:a" is explicitly a path relative to the CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in most windows programs) interpreted as a drive relative path.
For example, the ntpath module handles these cases correctly. When located in the directory C:\\d, this is the ntpath behavior:
ntpath.abspath('b:a') -> 'B:\\a'
ntpath.abspath('.\\b:a') -> 'C:\\d\\b:a'

In conclusion, I stand by my original fix offers. They are correct according to windows' documentation and behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________