[Python-Dev] pathlib - current status of discussions (original) (raw)

Koos Zevenhoven k7hoven at gmail.com
Tue Apr 12 13:31:21 EDT 2016

On Tue, Apr 12, 2016 at 6:52 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

(A) Why does anybody need bytes out of a pathlib.Path (or other fspath-toting, higher-level API) inside the boundary? Note that the APIs in os (etc) don't need bytes because they are already polymorphic.

Indeed not from pathlib.*Path , but from DirEntry, which may have a path as bytes. So the options for DirEntry (or things like Ethan's 'antipathy') are:

(1) Provide bytes or str via the protocol, depending on which type this DirEntry has

Downside: The protocol needs to support str and bytes.

(2) Decode bytes using os.fsdecode and provide a str via the protocol

Downside: The user passed in bytes and maybe had a reason to do so. This might lead to a weird mixture of str and bytes in the same code.

(3) Do not implement the protocol when dealing with bytes

Downside: If a function calling os.scandir accepts both bytes and str in a duck-typing fashion, then, if this adopted something that uses the new protocol, it will lose its bytes compatiblity. This risk might not be huge, so perhaps (3) is an option?

(B) If they do, why can't they just apply bytes() to the object? I understand that that would offend Ethan's aesthetic sense, so it's worth looking for a nice way around it. But allowing fspath to return bytes or str is hideous, because Paths are clearly on the application side of the boundary.

Note that bytes() may not have the serious problem that str() does of being too catholic about its argument: nothing in builtins has a bytes! Of course there are a few things that do work: ints, and sequences of ints.

Good point. But this only applies to when the user explicitly deals with bytes. But when the user just deals with the type (str or bytes) that is passed in, as os.path.* as well as DirEntry now do, this does not work.

-Koos

More information about the Python-Dev mailing list