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:
Your pathstring seems to be the same as the predefined (in typing.py, and PEP 484) AnyStr.
Oh, there too! :) I thought I will need a TypeVar, so I turned to help(typing.TypeVar) to look up how to do that, and there it was, right in front of me, just with a different name 'A':
A = TypeVar('A', str, bytes)
Anyway, it might make sense to consider defining 'pathstring' (or 'PathStr' for consistency?), even if it would be the same as AnyStr. Then, hypothetically, if at any point in the far future, bytes paths would be deprecated, it could be considered to make PathStr just str. After all, we don't want just Any String, we want something that represents a path (in a documentation sense).
Unfortunately, until we implement something like "NewType" ( https://github.com/python/typing/issues/189) the type checkers won't check whether you're actually using the right thing, so while the separate name would add a bit of documentation, I doubt that you'll ever be able to change the meaning of PathStr. Also, I don't expect a future where bytes paths don't make sense, unless Linux starts enforcing a normalized UTF-8 encoding in the kernel.
You are indeed making sense, except that for various reasons the stdlib is not likely to adopt in-line signature annotations yet -- not even for new code.
However once there's agreement on os.fspath() it can be added to the stubs in github.com/python/typeshed.
I see, and I did have that impression already about the stdlib and type hints, probably based on some of your writings. My intention was to write these in the stub format, but apparently I need to look up the stub syntax once more.
Once there's a PEP, updating the stubs will be routine.
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. -- --Guido van Rossum (python.org/~guido)