Paul Moore <p.f.mo...@gmail.com> added the comment:
> > [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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36305> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
