[Python-ideas] Type hinting for path-related functions

[Koos Zevenhoven]

On Tue, Apr 19, 2016 at 7:20 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Apr 19, 2016 at 3:41 AM, Koos Zevenhoven <k7hoven at gmail.com> wrote:
>>
>> On Tue, Apr 19, 2016 at 4:27 AM, Guido van Rossum <guido at python.org>
>> wrote:
>>
>> > Is there going to be a PEP for os.fspath()? (I muted most of the
>> > discussions
>> > so I'm not sure where it stands.)
>>
>> It has not seemed like a good idea to discuss this (too?), but now
>> that you ask, I have been wondering how optimal it is to add this to
>> the pathlib PEP. While the changes do affect pathlib (even the code of
>> the module itself), this will affect ntpath, posixpath, os.scandir,
>> os.[other stuff], DirEntry (tempted to say os.DirEntry, but that is
>> not true), shutil.[stuff], (io.)open, and potentially all kinds of
>> random places in the stdlib, such as fileinput, filecmp, zipfile,
>> tarfile, tempfile (for the 'dir' keyword arguments), maybe even glob,
>> and fnmatch, to name a few :).
>>
>> And now, if the FSPath[underlying_type] I just proposed ends up being
>> added to typing (by whatever name), this will even affect typing.py.
>
>
> Personally I think it's better off as a separate PEP, unless it turns out
> that it can be compressed to just the addition of a few paragraphs to the
> original PEP 428.
>

While I could imagine the discussions having been shorter, it does not
seem like compressing everything into a few paragraphs is a good idea
either. And there are things that have not really been discussed, such
as the details of the 'typing' part and the list of affected modules,
which I tried to sketch above. Anyway, after all this, I wouldn't mind
to also work on the PEP if there will be separate one---if that makes
any sense.

-Koos