| msg249936 - (view) |
Author: David Barnett (mu_mind) |
Date: 2015-09-05 22:05 |
| There doesn't seem to be any helper in pathlib to expand a relative path to an absolute path *without* resolving symlinks. For example, if I want to convert pathlib.Path('some/path') to pathlib.Path('/full/path/to/some/path') where some/path is a symlink, my best option seems to be pathlib.Path(os.path.abspath(str(pathlib.Path('some/path')))) |
|
|
| msg249941 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2015-09-05 22:24 |
| pathlib.Path.cwd() / pathlib.Path('some/path') |
|
|
| msg249968 - (view) |
Author: Eryk Sun (eryksun) *  |
Date: 2015-09-06 05:57 |
| There's a public method that's almost what you want: >>> print(pathlib.Path.absolute.__doc__) Return an absolute version of this path. This function works even if the path doesn't point to anything. No normalization is done, i.e. all '.' and '..' will be kept along. Use resolve() to get the canonical path to a file. However, it appears to be only accidentally public. It isn't tested; it isn't mentioned in the docs; and it doesn't do the [expected] path normalization. Currently it's used as a default in resolve() if self._flavour.resolve(self) returns None. |
|
|
| msg250129 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2015-09-07 20:56 |
| Yes, this wasn't meant to be a public method really. I'm still on the fence as to whether we should expose something like this. What is your use case? |
|
|
| msg250139 - (view) |
Author: David Barnett (mu_mind) |
Date: 2015-09-07 23:21 |
| The idiom of pathlib.Path.cwd() / pathlib.Path('some/path') isn't too bad of an approach if it could just be mentioned in the docs. I would intuitively expected something like pathlib.Path('some/path').resolve(follow_symlinks=False) 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. 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). |
|
|
| msg250167 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2015-09-08 07:39 |
| 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. |
|
|
| msg250208 - (view) |
Author: David Barnett (mu_mind) |
Date: 2015-09-08 14:25 |
| Right, and to clarify a bit further why I didn't just use A.resolve() == B.resolve() from the beginning, this is in a unit test where the equality check wasn't in my code. I wanted to assert I received a certain call on my mock, like mock_open_method.assert_called_once_with(pathlib.Path('foo')) so it's much more convenient to be able to create a path object that matches with my target path instead of more complicated matching. |
|
|
| msg250209 - (view) |
Author: David Barnett (mu_mind) |
Date: 2015-09-08 14:28 |
| And the symlinks for my paths refer to really cryptic hashes in a virtual filesystem for the tests, so rendering them into the assertion failed errors would really make the failure messages hard to interpret. |
|
|