[Python-Dev] file system path protocol PEP

[Brett Cannon]

On Thu, 12 May 2016 at 09:25 Guido van Rossum <guido at python.org> wrote:

> I am glad this is finally happening. There's quite a bit of noise in the
> thread which I have to ignore.
>

Don't worry, I'm not ignoring it on your behalf. :)


> The two issues that I want to respond to are speed and whether os.fspath()
> can return bytes.
>
> - Speed: We should trust our ability to optimize the implementations where
> necessary. First the API issues need to be settled.
>

Added a note to the PEP to say perf isn't a worry for os.path.


>
> - Bytes: I strongly believe that os.fspath() should be a thin wrapper
> around the __fspath__ protocol, like next() wraps the .__next__ protocol.
> It should not get into bytes vs. string politics. If your app really needs
> strings, call os.fsdecode(). So this is my version (unoptimized):
>
> def fspath(p: Union[str, bytes, PathLike]) -> Union[str, bytes]:
>     if isinstance(p, (str, bytes)):
>         return p
>     try:
>         return p.__fspath__
>     except AttributeError:
>         raise TypeError(...)
>

> Other than that I think the PEP is already in fine shape.
>

Just to double-check, did you mean for __fspath__ to only be an attribute
in your example, or did you leave off the `()` by accident? As of right now
the PEP is proposing a method for the protocol to follow common practice of
using methods and in case the representation is not always pre-computed and
thus not necessarily giving the wrong impression that the attribute access
is cheap. But admittedly an attribute was previously proposed and there
wasn't a terribly strong argument against it beyond "we historically
haven't done it that way", so I'm open to swapping to an attribute if
that's your preference.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160512/8020bf59/attachment.html>