On Tue, Apr 19, 2016 at 7:20 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Apr 19, 2016 at 3:41 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Tue, Apr 19, 2016 at 4:27 AM, Guido van Rossum <guido@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