You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
os.path.relpath() needlessly calls abspath() when given two paths with matching anchors #99199
relpath() unconditionally calls abspath() to make both its arguments absolute before comparing them. This is necessary if the supplied arguments have different anchors, but it is not necessary when the paths' anchors match. We can save a call to getcwd() / _getfinalpathname() by skipping the abspath() call in this case. This should improve performance a little.
For example, neither of the following should require a call to abspath() internally:
If we want to retain the ".." result here, then trailing dots and spaces will have to be stripped from the final component of each path. Otherwise the result will be "..\..\eggs. . .". There are also cases with DOS device names that will change if abspath() isn't called. For example, "foo/bar/nul" resolves to "\\.\nul".
Funnily enough normpath() doesn't apply that normalisation. The support for Windows normalisation rules in Python seems pretty patchy IMO. There's no provision for it in pathlib, for example.
Funnily enough normpath() doesn't apply that normalisation. The support for Windows normalisation rules in Python seems pretty patchy IMO. There's no provision for it in pathlib, for example.
I'd prefer for ntpath.normpath() to strip dots and spaces from the final component, except for a ".." name. This would also improve ntpath.abspath() on POSIX1.
Normalizing DOS device names is problematic because it depends on the Windows version. There's still consistent behavior for bare device names, such as "con" -> "\\.\con", but not "./con"2 or "con.txt".
Footnotes
The fallback on POSIX also needs better support for drives, and to use "C:" as the working drive. It should get drive, path = splitdrive(path), and then resolve the absolute path as join(drive or 'C:', cwd, path). ↩
ntpath.abspath() is implemented as _getfullpathname(normpath(path)). normpath() aggressively normalizes "./con" as "con", so abspath('./con') returns "\\.\con" even if the current Windows version doesn't reserve "./con". In general, removing a leading "." component is wrong on Windows. For example, "./C:spam" (a file named "C" with a data stream named "spam") differs from the drive-relative path "C:spam". ↩
Activity
eryksun commentedon Nov 7, 2022
On Windows,
abspath()also normalizes a path, such as stripping any trailing spaces and dots from the final component. For example:If we want to retain the ".." result here, then trailing dots and spaces will have to be stripped from the final component of each path. Otherwise the result will be "..\..\eggs. . .". There are also cases with DOS device names that will change if
abspath()isn't called. For example, "foo/bar/nul" resolves to "\\.\nul".barneygale commentedon Nov 9, 2022
Funnily enough
normpath()doesn't apply that normalisation. The support for Windows normalisation rules in Python seems pretty patchy IMO. There's no provision for it in pathlib, for example.eryksun commentedon Nov 9, 2022
I'd prefer for
ntpath.normpath()to strip dots and spaces from the final component, except for a ".." name. This would also improventpath.abspath()on POSIX1.Normalizing DOS device names is problematic because it depends on the Windows version. There's still consistent behavior for bare device names, such as "con" -> "\\.\con", but not "./con"2 or "con.txt".
Footnotes
The fallback on POSIX also needs better support for drives, and to use "C:" as the working drive. It should get
drive, path = splitdrive(path), and then resolve the absolute path asjoin(drive or 'C:', cwd, path). ↩ntpath.abspath()is implemented as_getfullpathname(normpath(path)).normpath()aggressively normalizes "./con" as "con", soabspath('./con')returns "\\.\con" even if the current Windows version doesn't reserve "./con". In general, removing a leading "." component is wrong on Windows. For example, "./C:spam" (a file named "C" with a data stream named "spam") differs from the drive-relative path "C:spam". ↩barneygale commentedon Nov 12, 2022
Ack, this doesn't work due to differences in collapsing leading
../segments:barneygale commentedon Nov 12, 2022
Closing this issue as the handling of
../segments inos.pathandpathlibcan't be reconciled in this case.