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

Nick Coghlan ncoghlan at gmail.com
Thu Apr 21 09:13:38 EDT 2016

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>

More information about the Python-Dev mailing list