[Python-Dev] pathlib - current status of discussions

[Koos Zevenhoven]

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