Le 08/09/2015 01:21, David Barnett a écrit :
> 
> My use case was that I had an equality check like this failing:
>   expected_path = pathlib.Path.cwd() / pathlib.Path('some/path')
>   pathlib.Path('some/path') == expected_path
> I suppose I should file that as a separate bug because semantically those paths are equal, but I was trying to work around it like
>   pathlib.Path('some/path').resolve() == expected_path
> which in my case still failed because some/path was a symlink.

Semantically, the paths are equal only in that particular system
configuration, with os.getcwd() pointing to a particular directory. Path
comparison is done on "pure" path objects (as explained in the
documentation) and therefore doesn't take into account system specifics.
This makes comparisons much more predictable.

Currently the way to implement "absolute" comparison is to call
.resolve() on both paths. Note you might care about actual file identity
and call os.path.samefile() instead.

> Even if that's fixed, I would still expect to run into cases where I
wanted to print specifically the relative or absolute path in
informational messages and would not want to follow symlinks (e.g., in
"Requested path X not found", the user would recognize the absolute path
as the one they entered but not necessarily the symlink-resolved version).

Yes... and yet that may be misleading, since the "absolute" path
obtained may not correspond to the actual one, especially if ".."
fragments are collapsed.

I'll have to think about this one a bit more.