`pathlib.WindowsPath` resolve() behavior discrepancy between windows paths and unix paths

[kdheepak]

Bug report

Bug description:

While working with pathlib.WindowsPath in Python, I am unable to compare two paths that Windows treats as the same:

import pathlib

path1 = pathlib.WindowsPath('/c/Temp/ServicesFix-3.4.Log')
path2 = pathlib.WindowsPath('C:/Temp/ServicesFix-3.4.Log')

print(path1 == path2)  # False
print(path1.resolve() == path2.resolve())  # False

print(path1.resolve())  # WindowsPath('C:/c/Temp/ServicesFix-3.4.Log')
print(path2.resolve())  # WindowsPath('C:/Temp/ServicesFix-3.4.Log')

This is also the cause of an unexpected warning when using ipython with uv on Windows: astral-sh/uv#7466

CPython versions tested on:

3.12

Operating systems tested on:

Windows

[rruuaanng]

pathlib.WindowsPath('/c/Temp/ServicesFix-3.4.Log') is usually considered an incorrect path on Windows, maybe they are the same. I think this's fine.

[y5c4l3]

I think it's out of pathlib scope.

From what I can recall, the converted path /c/xyz probably comes from the venv activate script, either Cygwin or MSYS2. Could you give the output of uname -a in your shell?

[Ravencentric]

Powershell v7.4.5 also rejects this and File Explorer opens them in browser instead (probably interpreting it as a network path?)

❯ pwsh --version
PowerShell 7.4.5

❯ Resolve-path ~/.yarnrc
C:\Users\raven\.yarnrc

❯ Resolve-path c:/Users/raven//.yarnrc
C:\Users\raven\.yarnrc

❯ Resolve-path \c\Users\raven\.yarnrc
Resolve-Path: Cannot find path 'C:\c\Users\raven\.yarnrc' because it does not exist.

❯ Resolve-path /c/Users/raven/.yarnrc
Resolve-Path: Cannot find path 'C:\c\Users\raven\.yarnrc' because it does not exist.

[ruema]

/c/Temp/ServicesFix-3.4.Log is a relative path to the current drive. Everything works as intended.
Windows knows about drives, and network pathes, which Posix doesn't.
pathlib handles these cases transparently, but if you convert pathes from other systems, you have to be careful.

[kdheepak]

My uname -a is MINGW64_NT-10.0-19045 ______ 3.4.10-2e2ef940.x86_64 2024-07-09 21:35 UTC x86_64 Msys.

If people think this is not a bug, I can close this issue.