[Python-ideas] Three ways of paths canonization

[Brett Cannon]

On Thu, 8 Sep 2016 at 09:46 Guido van Rossum <guido at python.org> wrote:

> I would prefer it if Path.resolve() resolved symlinks until it hits
> something that doesn't exist and then just keep the rest of the path
> unchanged. I think this is the equivalent of -m in the mentioned
> utility (which I had never heard of).
>
> It looks like os.path.realpath() already works this way.
>
> Steve Dower just mentioned to me that the Windows version of
> Path.resolve() uses a Windows API that opens the file and then asks
> the system for the pathname -- that doesn't work if the file doesn't
> exist, so it should be fixed to back off and try the same thing on the
> parent, etc.
>
> We should treat these things as bugs to fix before 3.6 (in 3.6b1 if
> possible) and make pathlib non-provisional as of 3.6.0.Probably these
> things should be fixed in 3.5.3 as well, since pathlib is still
> provisional there.
>

http://bugs.python.org/issue28031 to track this.

-Brett


>
> --Guido
>
> On Wed, Sep 7, 2016 at 7:47 AM, Stephen J. Turnbull
> <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
> > Serhiy Storchaka writes:
> >
> >  > The readlink utility from GNU coreutils has three mode for resolving
> >  > file path:
> >  >
> >  >         -f, --canonicalize
> >  >                canonicalize by following every symlink in every
> >  > component of the given name recursively; all but the last component
> must
> >  > exist
> >  >
> >  >         -e, --canonicalize-existing
> >  >                canonicalize by following every symlink in every
> >  > component of the given name recursively, all components must exist
> >  >
> >  >         -m, --canonicalize-missing
> >  >                canonicalize by following every symlink in every
> >  > component of the given name recursively, without requirements on
> >  > components existence
> >
> > In Mac OS X (and I suppose other BSDs), realpath(3) implements -e.
> > glibc does none of these, instead:
> >
> >    GNU extensions
> >        If the call fails with either EACCES or ENOENT and
> >        resolved_path is not NULL, then the prefix of path that is not
> >        readable or does not exist is returned in resolved_path.
> >
> > I suppose this nonstandard behavior is controlled by a #define, but
> > the Linux manpage doesn't specify it.
> >
> >  > Current behavior of posixpath.realpath() is matches (besides one minor
> >  > detail) to `readlink -m`. The behavior of Path.resolve() matches
> >  > `readlink -e`.
> >
> > This looks like a bug in posixpath, while Path.resolve follows POSIX.
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/realpath.html
> > sez:
> >
> >     RETURN VALUE
> >
> >     Upon successful completion, realpath() shall return a pointer to
> >     the resolved name. Otherwise, realpath() shall return a null
> >     pointer and set errno to indicate the error, and the contents of
> >     the buffer pointed to by resolved_name are undefined.
> >
> >     ERRORS
> >
> >     The realpath() function shall fail if:
> >
> > [...]
> >     [ENOENT] A component of file_name does not name an existing file or
> >         file_name points to an empty string.
> >     [ENOTDIR] A component of the path prefix is not a directory.
> >
> > which corresponds to -e.
> >
> >  > I have proposed a patch that adds three-state optional parameter to
> >  > posixpath.realpath() and I'm going to provide similar patch for
> >  > Path.resolve(). But I'm not sure this is good API. Are there better
> >  > variants?
> >
> > Said parameter will almost always be a constant.  Usually in those
> > cases Python prefers to use different functions.  Eg,
> >
> >     posixpath.realpath                    -e
> >     posixpath.realpath_require_prefix     -f
> >     posixpath.realpath_allow_missing      -m
> >     posixpath.realpath_gnuext             GNU extension
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160908/a86f7762/attachment.html>