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

Stephen J. Turnbull stephen at xemacs.org
Thu Apr 14 03:02:36 EDT 2016

I was going to read the new posts that came in since I started this one (at one point it was 5X as long as it is now), but this thread is way out of control. My apologies to anybody who has presented[1] use cases in support of the wildly speculative proposals under discussion, but my bet is that there have been none.

Victor Stinner writes:

Oops sorry, I forgot to add that I have no strong opinion on the type (I only have a minor preference for str only).

I have a strong preference for str only, because I still don't see a use case for polymorphic fspath.

os functions and os.path functions need to accept both str and bytes because they are interfaces to OS functionality used by both text and non-text applications, and so must check and convert to OS native type. Many of these function produce what they receive because both text and non-text applications use names of filesystem objects internally, as well as passing them to OS wrappers. The question is how far to take that logic.

So let me propose what I think is the elephant in the room. If you're going to have a polymorphic fspath, then pathlib is the example of a module that desperately needs to be polymorphic. Consider:

A non-text Application has some bytes and passes them to
    pathlib.Path as <type A>
manipulates them and passes the result to
    os.scandir as <type B>
expecting a return of
    DirEntries of <type C>

== == bytes, and == Path is TOOWTDI, no? But under the current proposal which doesn't touch the internal mechanisms of pathlib and allows, but has no way to request, bytes returns, == str, == Path, and == str, requiring two explicit conversions that bytes-shoveling developers will tell you should be unnecessary. QED, pathlib should be polymorphic as a central part of this proposal.

IMO that's not the right way to go (slippery slope, very quickly you hit manipulations that are "really" text operations). See also my proposal "Pathlib enhancements - improve fsdecode and fsencode" which suggests a (primitive) way for code to request the type it likes better.

But WDOT? I'd especially like to hear if Nick is tempted to flip-flop (so far he's been in the "pathlib is a text utility" camp).

Footnotes: [1] Just because I don't know of any I consider persuasive doesn't mean there aren't any, but what you don't tell me I don't know. (Maybe you'd have to kill me? If so, thanks for not telling!)

More information about the Python-Dev mailing list