> > [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...

Huh, weird. It's not in
https://docs.python.org/3.7/library/pathlib.html But you're right, it
does exist...

> > 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:.

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).

> > 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.

> 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'

That second case only results in a valid filename if b:a is viewed as
a file-with-stream, but the first only makes sense if b:a is viewed as
a directory-relative file.

Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path. Following documented
behaviour or not, that violates a pretty fundamental assumption that
users would expect to hold. 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.

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

I remain of the view that the Windows documentation introduces a
concept ("relative path to the current directory on a specific drive")
that isn't well modelled by the current APIs, and the only "proper"
solution is to extend the API (like with the ideas of "drive" and
"reserved filenames", which are Windows-specific, but supported
everywhere). In the absence of that, I believe that any "fix" within
the existing model will have odd edge cases, and I don't think these
ones (specifically the "./b:a" cases) have *any* "obvious" answer.

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" :-)

BTW, was there an actual use case for this issue, or was it simply a
theoretical concern? I'm actually much happier considering these cases
as "undefined" in practice (and just "not mentioned" in the docs),
rather than trying to pin it down precisely. I don't know of a case
where it actually benefits us to document this level of arguable
behaviour.