[Python-Dev] file system path protocol PEP (original) (raw)

Brett Cannon brett at python.org
Thu May 12 13🔞45 EDT 2016

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>

More information about the Python-Dev mailing list