(original) (raw)



On Thu, 12 May 2016 at 09:25 Guido van Rossum <guido@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.