<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 19, 2016 at 3:41 AM, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Tue, Apr 19, 2016 at 4:27 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> Your pathstring seems to be the same as the predefined (in typing.py, and<br>
> PEP 484) AnyStr.<br>
<br>
</span>Oh, there too! :) I thought I will need a TypeVar, so I turned to<br>
help(typing.TypeVar) to look up how to do that, and there it was,<br>
right in front of me, just with a different name 'A':<br>
<br>
A = TypeVar('A', str, bytes)<br>
<br>
Anyway, it might make sense to consider defining 'pathstring' (or<br>
'PathStr' for consistency?), even if it would be the same as AnyStr.<br>
Then, hypothetically, if at any point in the far future, bytes paths<br>
would be deprecated, it could be considered to make PathStr just str.<br>
After all, we don't want just Any String, we want something that<br>
represents a path (in a documentation sense).<span class=""><br></span></blockquote><div><br></div><div>Unfortunately, until we implement something like "NewType" (<a href="https://github.com/python/typing/issues/189">https://github.com/python/typing/issues/189</a>) 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.<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> You are indeed making sense, except that for various reasons the stdlib is<br>
> not likely to adopt in-line signature annotations yet -- not even for new<br>
> code.<br>
><br>
> However once there's agreement on os.fspath() it can be added to the stubs<br>
> in <a href="http://github.com/python/typeshed" rel="noreferrer" target="_blank">github.com/python/typeshed</a>.<br>
><br>
<br>
</span>I see, and I did have that impression already about the stdlib and<br>
type hints, probably based on some of your writings. My intention was<br>
to write these in the stub format, but apparently I need to look up<br>
the stub syntax once more.<span class=""><br></span></blockquote><div><br></div><div>Once there's a PEP, updating the stubs will be routine.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Is there going to be a PEP for os.fspath()? (I muted most of the discussions<br>
> so I'm not sure where it stands.)<br>
<br>
</span>It has not seemed like a good idea to discuss this (too?), but now<br>
that you ask, I have been wondering how optimal it is to add this to<br>
the pathlib PEP. While the changes do affect pathlib (even the code of<br>
the module itself), this will affect ntpath, posixpath, os.scandir,<br>
os.[other stuff], DirEntry (tempted to say os.DirEntry, but that is<br>
not true), shutil.[stuff], (io.)open, and potentially all kinds of<br>
random places in the stdlib, such as fileinput, filecmp, zipfile,<br>
tarfile, tempfile (for the 'dir' keyword arguments), maybe even glob,<br>
and fnmatch, to name a few :).<br>
<br>
And now, if the FSPath[underlying_type] I just proposed ends up being<br>
added to typing (by whatever name), this will even affect typing.py.<span class=""></span><br></blockquote></div><br></div><div class="gmail_extra">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.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>