Home Original page

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

Guido van Rossum guido at python.org
Tue Apr 19 12:20:48 EDT 2016 
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:
> > 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160419/dc95ab2b/attachment.html>
More information about the Python-ideas mailing list