[Python-Dev] Pathlib enhancments - method name only

[Nick Coghlan]

On 10 April 2016 at 15:58, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Brett Cannon wrote:
>
>> Depends if you use `/` or `\` as your path separator
>
>
> Or whether your pathnames look entirely different, e.g VMS:
>
>   device:[topdir.subdir.subsubdir]filename.ext;version
>
> Pathnames are very much OS-dependent in both syntax *and* semantics.
>
> Even the main two in use today (unix and windows) can't be
> mapped directly onto each other, because windows has drive
> letters and unix doesn't.

This does raise a concrete API design question: how should
PurePath.__fspath__ behave when called on a mismatched OS?

For PurePath vs Path, the latter raises NotImplementedError if you try
to create a concrete path that doesn't match the running system:

   >>> pathlib.PureWindowsPath(".")
   PureWindowsPath('.')
   >>> pathlib.WindowsPath(".")
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/lib64/python3.4/pathlib.py", line 910, in __new__
       % (cls.__name__,))
   NotImplementedError: cannot instantiate 'WindowsPath' on your system

The question we need to address is what happens if you do:

   >>> os.fspath(pathlib.PureWindowsPath("."))

on a *nix system?

Similar to my proposal for dealing with DirEntry.path being a
bytes-like object, I'd like to suggest raising TypeError in __fspath__
if the request is nonsensical for the currently running system - *nix
systems can *manipulate* Windows paths (and vice-versa), but actually
trying to *use* them with the local filesystem isn't going to work
properly, since the syntax and semantics are different.

   >>> os.fspath(pathlib.WindowsPath("."))
   Traceback (most recent call last):
       ...
   TypeError: cannot render 'PureWindowsPath' as filesystem path on
'posix' system

(I'm also suggesting replacing "your" with the value of os.name)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia