On Thu, 12 May 2016 at 09:25 Guido van Rossum <gu...@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. >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
