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

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> 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 directory. 

Note that Windows allows a trailing colon for DOS devices such as "con:". Colons can also be used for file streams, but "cc:" isn't valid. The anonymous stream can only be specified explicitly by including the stream type, e.g. "cc::$DATA".

> WindowsPath('c:').is_absolute() -> False
> WindowsPath('c:p').is_absolute() -> False
> WindowsPath('c:') / 'p' -> WindowsPath('c:p')

These are correct. Drive-relative paths depend on the current working directory of the drive. By definition they cannot be absolute. And the last one can be no more resolved than WindowsPath('spam/eggs') / 'p'. 

Note that Windows gets the working directory for drives from 'hidden' environment variables such as "=C:". If no value is set for a drive, it defaults to the root directory. Windows uses these values, but never sets them itself. Applications and libraries such as the C runtime library are responsible for setting the values. CMD and Python both set them, but PowerShell does not. 

> WindowsPath('c:').absolute() -> WindowsPath('c:') 
> WindowsPath('c:p').absolute() -> WindowsPath('c:p')

This is a bug. absolute() should resolve "C:" to the current directory on the drive and join it with the remaining parts.

----------
nosy: +eryksun
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________