[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

[Nick Coghlan]

On 20 April 2016 at 13:16, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> What's left is DirEntry (and perhaps other producers of byte-oriented
> objects in os and os.path).  If they're currently using DirEntry,
> they're currently accessing .path.  Surely bytes users can continue
> doing that, even if we offer str users the advantage of new protocols?
>

The consuming functions aren't currently allowing DirEntry objects either
(since scandir is even newer than pathlib), so we want to allow both
pathlib and DirEntry objects with a single change to consuming functions.

I'd like to see that change in consuming functions be as simple as
possible: an unconditional "path = os._raw_fspath(path)" at the start of
their existing input processing

Those consuming functions fall into one of three categories:

1. They're bytes/str polymorphic
2. They're bytes only
3. They're str only

Whichever category they're in, their existing argument processing will be
readily able to cope with a polymorphic result from os._raw_fspath, since
that's no different from today, where the argument passed in may be bytes
or str and they need to handle that appropriately.

Having os.fspath(path) as a specifically str-only layer then gives
consuming functions in category 3 an alternative option, and encourages
category 3 functions and APIs (like pathlib) as the future default, without
getting in the way of the folks that need to mess about down in the low
level weeds of operating system interfaces.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160421/eac042ac/attachment.html>