[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Change by Eryk Sun : -- versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list maili

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: > Is this related to the weird paths I am seeing when getting different output > in venv compared to without venv This is probably not related, sounds like something caused by the venv implementation. On a different note, how do I get my PR reviewed? (ht

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

NM added the comment: Is this related to the weird paths I am seeing when getting different output in venv compared to without venv: from pathlib import Path filename = Path(__file__) filename2 = Path('C:\\path\\to\\file.py') print(filename) print(filename2) Where the result is: --

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: Alright. And what is left to do with the current issue? -- ___ Python tracker ___ ___ Python-bu

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Eryk Sun added the comment: > In contrast, in the case of CreateProcessW, both Path('./exec') and > Path('exec') are the *correct* paths to the executable. The ./ is not > necessary in that case to display the path correctly, but just to > interact correctly with CreateProcessW's interface.

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: What can we do in order to make progress here? -- ___ Python tracker ___ ___ Python-bugs-list m

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: > Ah, I think I follow now. But I'm not sure what you mean by wanting it to > "retain an initial '.' component" - how would you expect that to work in > practice? p1.parts == ('.', 'c:a')? I suspect that could break existing code. I've dealt with that in m

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: > There's no way to split it up as the joining of two pathlib paths because > there is no way to represent "c:a" by itself as anything other than a > drive-relative path. The name "./c:a" has to be taken as a unit, which is > fundamentally different from "c:a".

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Eryk Sun added the comment: Paul, I agree that joining Path(".") and Path("c:a") should yield Path("c:a"). However, I disagree that we should always be able to construct Path("a/b") from components Path("a") and Path("b"). It doesn't apply to Path("./c:a"). There's no way to split it up as t

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: Alright, documentation is always good :) I'll be glad to add some, but could you please point me to the place in the code where you think it should go? (or just comment on the PR) -- ___ Python tracker

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: > does that require me to make any changes in order to make progress with my PR? I'm not going to block this PR. I'd prefer it if we at least documented the agreed behaviour, so that in future people don't come along and say the new behaviour is wrong, but again I

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger 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 dea

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore 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... > > i

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: > (Note: I consider all of these to be *extremely* obscure corner cases) One bug was enough for me :) > [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... > it seem

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: (Note: I consider all of these to be *extremely* obscure corner cases) > 1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but > returns WindowsPath('C:a'). > This is caused by flawed logic in the parse_parts method of the _Flavour > class.

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: Update after editing my PR - the bugs are: 1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but returns WindowsPath('C:a'). This is caused by flawed logic in the parse_parts method of the _Flavour class. 2. WindowsPath('./b:a').absolu

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Change by Maor Kleinberger : -- keywords: +patch pull_requests: +12328 stage: test needed -> patch review ___ Python tracker ___ ___

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Change by Terry J. Reedy : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___ ___

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Maor Kleinberger added the comment: I agree. So I'll open a PR that will: 1. Make the .absolute method return correct values in these cases 2. Add a regression test for this behavior -- ___ Python tracker __

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Eryk Sun added the comment: > WindowsPath('cc:').absolute() -> WindowsPath('C:/Users/maor/cc:') This is correct. "cc:" is not a drive, i.e. the `drive` attribute is an empty string. pathlib handles this as an unqualified filename that gets resolved relative to the process current working dir

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

New submission from Maor Kleinberger : The behavior of WindowsPath is undefined when used with drive paths, specifically with no trailing slash: WindowsPath('cc:').absolute() -> WindowsPath('C:/Users/maor/cc:') WindowsPath('c:').absolute() -> WindowsPath('c:') WindowsPath('c:').is_absolute()