(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 ptry: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.