Maor Kleinberger <kma...@gmail.com> added the comment:
> 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.
----------
_______________________________________
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
