Message338669
> (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 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:.
> 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.
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'
In conclusion, I stand by my original fix offers. They are correct according to windows' documentation and behavior. |
|
Date |
User |
Action |
Args |
2019-03-23 11:50:30 | kmaork | set | recipients:
+ kmaork, paul.moore, tim.golden, zach.ware, eryksun, steve.dower |
2019-03-23 11:50:29 | kmaork | set | messageid: <1553341829.99.0.558639039335.issue36305@roundup.psfhosted.org> |
2019-03-23 11:50:29 | kmaork | link | issue36305 messages |
2019-03-23 11:50:29 | kmaork | create | |
|