[Python-Dev] file system path protocol PEP

[Brett Cannon]

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

> On Thu, May 12, 2016 at 11:51 AM, Brett Cannon <brett at python.org> wrote:
>
>>
>> Anyway, with your strong preference of how to tweak os.fspath() what
>> specifically would you like to see discussed at this point?
>>
>
> Preferably nothing. :-) There's been too much discussion already.
>

Works for me. :) I'll update the PEP with the new semantics for os.fspath()
and send out the updated version later today.


>
>
>> Assuming the os.fspath() -> bytes discussion is dealt with, the only open
>> issues listed in the PEP are the naming and placement of the ABC and how to
>> do type hints for all of this (thanks to the dichotomy of path objects
>> using the protocol and path-like objects which is the union of path object,
>> str, and bytes and the joy of trying to name all of this well).
>>
>
> Name and placement: I think it belongs in os, and os.PathLike sounds like
> a fine name. (I'm surprised that os.DirEntry doesn't exist.)
>

SGTM. And os.DirEntry doesn't exist simply because it's posix.DirEntry
since it's implemented entirely in C. We could add an alias but since it
isn't constructed from scratch I don't think it's worth it.


>
> Typing: do you want it to be a generic class? If not, the types can be
> left out of the stdlib and only put in the stub (though you can show them
> in the PEP of course).
>

If we aren't going to restrict what os.fspath() returns then I don't see
any need to make the type generic (I mean technically a generic version
might be nice for e.g. the constructor of pathlib only taking strings, but
it's probably overkill).

I guess my real question is whether we want to create typing.PathLike to
match os.PathLike? And it sounds like you don't want to bother with a
potential second type that corresponds to Union[str, bytes, PathLike].


>
> If you want it to be generic we have more work to do. I'm out of time now
> but we can discuss that after 3pm today.
>

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