> OK, sure. My point is that "relative path to the current directory on
the drive with the specified letter" isn't a concept that matches how
"relative paths" are typically interpreted (most code interprets
"relative" as "relative to the CWD", and doesn't deal with the
possibility of per-drive CWDs).

In pathlib, each path object has a drive, a root and path parts. Seeing pathlib's logic and tests (many tests are specifically testing the behavior of drive-relative paths), I think pathlib completely supports drive relative paths, with the exception of a few small bugs.


> > > 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.
> Windows is inconsistent here - it can *also* be interpreted as a path
to a stream within a file. But it (virtually) never is.

I think that when parsing windows paths, pathlib should behave exactly like the windows API does. This is crucial for interaction with the windows API itself or with other applications that might use it. I don't see any other way to parse windows paths other than according to the normal windows behavior.
Having said that, pathlib does a pretty good keeping the compatibility with the windows API, except for the small cases I found and brought forward in this issue report. From the information I gathered, when a path starts with one letter followed by a colon, windows treats it as a drive and continues parsing the rest of the path separately. That means that if you want to specify a path to a file in the CWD, with a single-character name and a file stream, you must precede the path with a "./" (See eryksun's comment on my PR before I fixed it https://github.com/python/cpython/pull/12361#discussion_r266193727).
Here is an example for the behavior of the windows API in this case:
win32api.GetFullPathName('b:a') -> 'B:\\a'
win32api.GetFullPathName('./b:a') -> 'C:\\Users\\maor\\b:a'


> Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path.

This behavior is completely normal. Should WindowsPath('C:\\f') / WindowsPath('D:\\f2') return anything other than WindowsPath('D:/f2')?


> And I think the problem is that "drive-relative paths" are somewhat odd things that don't fit well in the POSIX-derived model that Python's path APIs follow.

As I wrote earlier, I think this is incorrect as the pathlib.Path class holds the attributes _drv, _root and _parts, which allows it to fully support drive-relative paths, by having a _drv and not having a _root.


> I'm happy to agree to differ on this point, though. If the new
behaviour is just a side-effect of fixing absolute() to match the
cases Eryk commented on, then that's fine - I just wouldn't describe
the particular ./b:c cases as "bug fixes", rather as "changes in the
behaviour of cases no-one should actually care about" :-)

I'm still that my case is convincing enough, but if not - does that require me to make any changes in order to make progress with my PR?


> BTW, was there an actual use case for this issue, or was it simply a
theoretical concern?

I've had an annoying bug using pathlib, traced it to the first bug I've presented in this issue, and discovered a few similar unhandled edge cases. Again, the "bugginess" I set upon to fix (call it a bug or  an undefined behavior) is an incompatibility issue with the way paths are normally treated in windows.