[Python-ideas] Three ways of paths canonization

[Koos Zevenhoven]

On Wed, Sep 7, 2016 at 12:20 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> Before removing provisional state from the pathlib module, we should resolve
> the issue with Path.resolve(). It corresponds to os.path.realpath(), but
> behaves differently in case of non-existent path. Actually we can't say that
> any of these functions is wrong. Both behaviors make sense in different
> situations.
>

Oh, almost missed this email.

I won't be able to look into the issue you bring up at the moment.
However, to be honest, I keep coming back to the thought that pathlib
should have another provisional cycle. As the new fspath protocol (PEP
519) will be released in 3.6, the experimentation with pathlib has
still been very limited. Since pathlib was not compatible with the
rest of the stdlib, the limited experimentation that was done
previously is not even completely valid, because PEP 519 makes the
situation a little different. And there are some rough edges there,
which make some things a little awkward. Removing the provisional
status now might lead to the module becoming a mere burden, as
third-party variations become significantly better.

-- Koos

> 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
>
> Current behavior of posixpath.realpath() is matches (besides one minor
> detail) to `readlink -m`. The behavior of Path.resolve() matches `readlink
> -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?
>
> [1] http://bugs.python.org/issue19717
> [2] http://bugs.python.org/issue27002
>
> _______________________________________________
> 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/



-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +