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)