Title: Add support for Path.absolute()
Type: enhancement Stage: patch review
Components: Documentation, Library (Lib) Versions: Python 3.10, Python 3.9, Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: 4-launchpad-kalvdans-no-ip-org, Jim Fasarakis-Hilliard, barneygale, brett.cannon, docs@python, eryksun, methane, pitrou, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2017-03-01 17:37 by Jim Fasarakis-Hilliard, last changed 2021-06-12 15:08 by barneygale.

Pull Requests
URL Status Linked Edit
PR 384 closed Jim Fasarakis-Hilliard, 2017-03-01 17:38
PR 26153 open barneygale, 2021-05-15 22:09
Messages (13)
msg288767 - (view) Author: Jim Fasarakis-Hilliard (Jim Fasarakis-Hilliard) * Date: 2017-03-01 17:37
Method absolute of Path objects lacked documentation, proposed PR adds relevant method to docs.
msg288923 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-03-03 20:37
As brought up on the PR, it turns out Path.absolute() is extremely under-tested.

Perhaps we should deprecate Path.absolute() instead of document it and properly test it (and the testing will be necessary to move forward with the documentation)? Path.resolve() handles absolute paths already while also resolving '.' and '..': It also works with non-existent paths so unless there's some performance issue I'm not aware of for resolving '.' and '..', then I say we deprecate Path.absolute().
msg288931 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-03-03 21:17
I've closed the PR on GitHub until we decide whether we just want to deprecate Path.absolute() in favour of Path.resolve().
msg289413 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-03-10 22:14
I'm still thinking about this but I'm still leaning towards deprecating pathlib.absolute().
msg289436 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-03-11 05:17
resolve() can't replace absolute(). They serve different purposes. Sometimes one wants an absolute path, but without resolving symbolic links. 

absolute() processes a path as a string, which will continue to be true if it's updated to call nt._getfullpathname (GetFullPathName) on Windows. OTOH, resolve() can outright fail on Windows. I can write up a list of examples (I can think of 5 or 6 unhandled error codes), but it's not directly relevant to this issue.
msg289452 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-03-11 18:43
I know it has it's uses (avoiding stat calls is one of them), but it is still undocumented, untested, and has two comments in it saying it needs work. Because of all that it might as well not exist since it doesn't meet our standards of quality.

If someone wants to fix all those issues then we can properly document it as supported, but if no one is willing to then I don't think we should leave unsupported code lying around that people might discover through dir().

And it doesn't serve a _different_ purpose compared to resolve(), it serves a _subset_ of resolve()'s purpose since resolve() calls absolute() unconditionally.
msg289460 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-03-12 00:47
What's the rationale for not calling self._flavour.pathmod.abspath() to implement absolute()? For example:

    >>> p = pathlib.Path('C:/con')
    >>> p._flavour.pathmod.abspath(p)
    >>> p._from_parts((p._flavour.pathmod.abspath(p),), init=False)

That's almost right except for an unrelated problem that pathlib shouldn't append a trailing slash for \\.\ local device paths. Doing so creates a different path, which may be invalid. \\.\con is a symbolic link to \Device\ConDrv\Console, and adding a trailing backslash after the "Console" filename is invalid. An example where the resulting path is valid but wrong is the volume device \\.\C:, which is a link to something like \Device\HarddiskVolume2. Appending a backslash refers to the root directory of the file system on the volume.
msg289507 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-03-12 20:26
"What's the rationale for not calling self._flavour.pathmod.abspath() to implement absolute()?" Beats me. :) It's just how Antoine wrote it and that's all I know.
msg289509 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-03-12 20:52
posixpath.abspath() collapses "<path>/<symlink>/.." to "<path>", this is not correct. Not sure about ntpath.abspath().
msg289526 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2017-03-13 02:58
> posixpath.abspath() collapses "<path>/<symlink>/.." to "<path>", this is not correct. Not sure about ntpath.abspath().

I feel this is reasonable limitation, and expected behavior for some cases.
So I think adding note about this in document is enough.
msg358642 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2019-12-18 19:46
I have opened to track updating the pathlib docs to have a section on getting the absolute path in various ways along with what the trade-offs are for each approach.
msg393731 - (view) Author: Barney Gale (barneygale) * Date: 2021-05-15 22:19
New PR up here:

The correspondence between `pathlib` and `os.path` is as follows:

- `Path.resolve()` is roughly `os.path.realpath()`
- `Path.absolute()` is roughly `os.path.abspath()`


- `resolve()` always raises RuntimeError on symlink loops, whereas `realpath()` either raises OSError or nothing depending on *strict*.
- `absolute()` doesn't normalize the path, whereas `abspath()` does. Normalizing without resolving symlinks can change the meaning of the path, so pathlib does the better thing here.
msg395689 - (view) Author: Barney Gale (barneygale) * Date: 2021-06-12 15:08
Hi - please could a core dev review PR 26153? It adds documentation and tests for Path.absolute(). Thank you!
Date User Action Args
2021-06-12 15:08:45barneygalesetmessages: + msg395689
2021-05-15 22:19:38barneygalesetmessages: + msg393731
2021-05-15 22:09:49barneygalesetkeywords: + patch
nosy: + barneygale

pull_requests: + pull_request24787
stage: patch review
2021-03-17 07:10:19eryksunlinkissue25012 superseder
2021-03-17 07:08:51eryksunsetmessages: - msg289517
2021-03-13 03:39:25eryksunsetassignee: docs@python
type: enhancement
components: + Library (Lib)
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.5, Python 3.6, Python 3.7
2020-10-19 12:40:074-launchpad-kalvdans-no-ip-orgsetnosy: + 4-launchpad-kalvdans-no-ip-org
2019-12-18 19:46:31brett.cannonsetmessages: + msg358642
2017-03-13 16:38:23brett.cannonsetassignee: brett.cannon -> (no value)
2017-03-13 02:58:49methanesetnosy: + methane
messages: + msg289526
2017-03-13 00:06:31eryksunsetmessages: + msg289517
2017-03-12 20:52:49serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg289509
2017-03-12 20:26:41brett.cannonsetmessages: + msg289507
2017-03-12 00:47:05eryksunsetmessages: + msg289460
2017-03-11 18:43:22brett.cannonsettitle: Add support for Path.absolute -> Add support for Path.absolute()
2017-03-11 18:43:17brett.cannonsettitle: Document Path.absolute -> Add support for Path.absolute
2017-03-11 18:43:06brett.cannonsetmessages: + msg289452
2017-03-11 05:17:14eryksunsetnosy: + eryksun
messages: + msg289436
2017-03-10 22:14:26brett.cannonsetmessages: + msg289413
2017-03-03 21:20:32serhiy.storchakasetnosy: + pitrou
2017-03-03 21:17:05brett.cannonsetmessages: + msg288931
2017-03-03 20:37:32brett.cannonsetmessages: + msg288923
2017-03-02 18:56:01brett.cannonsetassignee: docs@python -> brett.cannon

nosy: + brett.cannon
2017-03-01 17:38:12Jim Fasarakis-Hilliardsetpull_requests: + pull_request321
2017-03-01 17:37:28Jim Fasarakis-Hilliardcreate