Repository navigation
ntpath.abspath() always return absolute path #119826
Description
Feature or enhancement
Proposal:
ntpath.abspath() doesn't always return an absolute path:
>>> import ntpath
>>> ntpath.abspath('C:\x00')
'C:\x00' # instead of 'C:\\Users\\wanne\\\x00'
>>> ntpath.abspath('\x00:')
'\x00:' # instead of '\x00:\\'Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Activity
nineteendo commentedon May 31, 2024
See current changes: https://github.com/python/cpython/compare/main...nineteendo:cpython:fix-ntpath.abspath?expand=1
nineteendo commentedon May 31, 2024
cc @barneygale, @eryksun
eryksun commentedon May 31, 2024
I'm mostly concerned with fixing
abspath()on Windows, by (1) using a private_path_normpath_ex()function that supports preserving a leading "." component, and (2) fixing the fallback implementation to correctly support drive-relative paths.The case of
normpath('C:.')is a bug in the C implementation that can be fixed. The pure Python implementation ofntpath.normpath()returns the correct result, "C:".Note that no changes are required for the documented behavior and call signature of
normpath()itself.@barneygale,
pathlib.PureWindowsPathwas changed in 3.12+ to preserve an explicit leading "." in the case of relative paths that are ambiguous with drive-relative paths, such as ".\C:spam", but not generally for relative paths, such as ".\con". Would it possible and reasonable to makepathlib.PureWindowsPathalways preserve an explicit initial ".", or maybe if there's only one subsequent component?barneygale commentedon May 31, 2024
I think this is too likely to break users code if
Path('foo')andPath('./foo')no longer hash/compare equal. There may be cases where users are relying on pathlib to remove that leading./.The dropping of leading
./and trailing/is called out in the pathlib docs from 3.13: https://docs.python.org/3.13/library/pathlib.html#comparison-to-the-os-and-os-path-modulesI wish I could fix it :( but I can't see a route that won't cause unreasonable breakage. I wish we'd caught this while pathlib was still provisional.
nineteendo commentedon Jun 2, 2024
I split up the pull request to make it easier to review. Feel free to take a look if you have time.
gh-119826: Improved fallback for ntpath.abspath() on Windows (GH-119938)
[-]Improve accuracy of `ntpath.normpath()` & `ntpath.abspath()`[/-][+]`ntpath.abspath()` always return absolute path[/+]picnixz commentedon Nov 14, 2024
Originally posted by @nineteendo in #119938 (comment)
Let's address the above points to decide whether this one should be closed as completed or not.
cc @erlend-aasland
nineteendo commentedon Nov 14, 2024
The issue has already been split up, so we should decide whether always returning an absolute path for
abspath()is a bug fix or feature.nineteendo commentedon Nov 21, 2024
@zooba, can this be closed?
pythongh-119826: Improved fallback for ntpath.abspath() on Windows (p…
pythongh-119826: Improved fallback for ntpath.abspath() on Windows (p…
gh-119826: Improved fallback for ntpath.abspath() on Windows (GH-119938)
gh-119826: Improved fallback for ntpath.abspath() on Windows (GH-119938)
nineteendo commentedon Dec 3, 2024
Thanks.
pythongh-119826: Improved fallback for ntpath.abspath() on Windows (p…
pythongh-119826: Improved fallback for ntpath.abspath() on Windows (p…