`ntpath.abspath()` always return absolute path

[nineteendo]

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

Links to previous discussion of this feature:

• Speedup posixpath.abspath() for relative paths #117587

Linked PRs

• gh-119826: ntpath.abspath() always return absolute path #119938
• [3.12] gh-119826: Improved fallback for ntpath.abspath() on Windows (GH-119938) #127534
• [3.13] gh-119826: Improved fallback for ntpath.abspath() on Windows (GH-119938) #127535

[nineteendo]

See current changes: https://github.com/python/cpython/compare/main...nineteendo:cpython:fix-ntpath.abspath?expand=1

[nineteendo]

cc @barneygale, @eryksun

[eryksun]

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 of ntpath.normpath() returns the correct result, "C:".

Note that no changes are required for the documented behavior and call signature of normpath() itself.

@barneygale, pathlib.PureWindowsPath was 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 make pathlib.PureWindowsPath always preserve an explicit initial ".", or maybe if there's only one subsequent component?

[barneygale]

Would it possible and reasonable to make pathlib.PureWindowsPath always preserve an explicit initial ".", or maybe if there's only one subsequent component?

I think this is too likely to break users code if Path('foo') and Path('./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-modules

I 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]

I split up the pull request to make it easier to review. Feel free to take a look if you have time.