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

Nick Coghlan ncoghlan at gmail.com
Wed Apr 13 10:21:37 EDT 2016

On 14 April 2016 at 00:11, Paul Moore <p.f.moore at gmail.com> wrote:

On 13 April 2016 at 14:51, Nick Coghlan <ncoghlan at gmail.com> wrote:

The potentially SE-strings only come back when you pass str, and the operating system data isn't properly encoded according to the nominal filesystem encoding. They round trip nicely to other operating system APIs, but can indeed be a problem if they escape to other parts of your program If the operating system APIs handle SE-strings correctly, is it not acceptable to require the fspath protocol to return strings, and then places like DirEntry or Ethan's module, when they want to return bytes, can just SE-encode the bytes and return those? Or will the fspath protocol be used at a low enough level that it's below the point where SE-encoded strings are handled properly?

I'd expect the main consumers to be os and os.path, and would honestly be surprised if we needed many explicit invocations above that layer, other than in pathlib itself.

That's actually the main factor in my suggesting the two level API design - from a protocol consumer perspective, bytes-or-str is a natural fit for os and os.path, while str-only is a natural fit for pathlib.

I also now believe it makes sense to postpone a final decision on this aspect of the design until after a draft implementation has been put together, as my and Ethan's assumption that os and os.path will be the main consumers is exactly that: an assumption. Putting the draft implementation together will let us know whether or not it's an accurate one.

Cheers, Nick.

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

More information about the Python-Dev mailing list