Regression in pathlib.resolve() in Python 3.13.1

Bug report

Bug description:

The strict argument in of pathlib.resolve() raises an unexpected exception where it should not and did not before in python 3.12 when using python 3.13.1. (Using the current build from debian-testing.

The issue is then

Traceback (most recent call last):
  File "foo.py", line 2, in <module>
    pathlib.Path(__file__, "../testpath").resolve(strict=True)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.13/pathlib/_local.py", line 672, in resolve
    return self.with_segments(os.path.realpath(self, strict=strict))
                              ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "<frozen posixpath>", line 448, in realpath

How to reproduce the error

import pathlib
import subprocess
import sys

pathlib.Path("testpath").mkdir(exist_ok=True)
pathlib.Path("test.py").write_text(
    """
import pathlib
pathlib.Path(__file__, "../testpath").resolve(strict=True)
""",
    encoding="utf-8",
)
result = subprocess.run([sys.executable, "test.py"], check=False, capture_output=True)
print(result.stderr)
print(result.stdout)
assert result.returncode == 0

The call pathlib.Path(__file__, "../testpath").resolve(strict=True) actually fails. What surprisingly does not fail in python 3.13.1 is pathlib.Path(__file__, "../testpath").resolve().resolve(strict=True)

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[barneygale]

Full traceback is something like:

Traceback (most recent call last):
  File "/home/barney/projects/cpython/repro.py", line 2, in <module>
    pathlib.Path(__file__, "../testpath").resolve(strict=True)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/home/barney/projects/cpython/Lib/pathlib/_local.py", line 1002, in resolve
    return self.with_segments(os.path.realpath(self, strict=strict))
                              ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "<frozen posixpath>", line 405, in realpath
  File "<frozen posixpath>", line 455, in _realpath
NotADirectoryError: [Errno 20] Not a directory: '/home/barney/projects/cpython/repro.py'

It's not pathlib-specific - you get the same thing from os.path.realpath('notadir/..', strict=True) on posix.

The 3.13.1 behaviour is correct IMO and it matches coreutils realpath. It was changed to fix this bug

Thanks for looking into it!

From a user perspective this is a regression and logically it makes little sense to me. The Pathlib class supports passing multiple fragments so of course I expect the resolve(strict=True) method/argument to work on the concatenated and resolved resulting path but nothing else.

[barneygale]

Maybe try this in terminal:

$ touch test.py
$ realpath -e test.py/bar
realpath: test.py/bar: Not a directory

We get "Not a directory" because we're treating a file as if it were a directory.

Indeed, I do not disagree with that. However, as a user I see little to no value in the new behavior. Using realpath is an implementation detail I do not care about, when using a method called resolve(). My code may receive a Path like object via it's API and writing passed_path.resolve().resolve(strict=True) instead of passed_path.resolve(strict=True) for catching an implementation detail is challenging to understand :)

[barneygale]

The behaviour matches the documentation:

If a path doesn’t exist or a symlink loop is encountered, and strict is True, OSError is raised.

I don't understand why you're using path.joinpath('..').resolve(strict=True) to find the parent directory. Why not path.parent? Or path.with_name() if you're intending to join on another path?

[vianney504]

Hello Le mer. 29 janv. 2025, 10:19, Barney Gale ***@***.***> a écrit :

…

The behaviour matches the documentation: If a path doesn’t exist or a symlink loop is encountered, and *strict* is True, OSError <https://docs.python.org/3/library/exceptions.html#OSError> is raised. I don't understand why you're using path.joinpath('..').resolve(strict=True) to find the parent directory. Why not path.parent? Or path.with_name() if you're intending to join on another path? — Reply to this email directly, view it on GitHub <#129391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BO3UVX5TXXXRJKKNA3T647T2NCTJLAVCNFSM6AAAAABV764JLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRRGIZDEMBUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[barneygale]

I've had my morning coffee and realise I've been quite short in my responses so far. Sorry about that! I do appreciate you making this report and bringing it to my attention :-).

No worries, I really appreciate that you are taking care!

My concern with this that I may not have the Path-Like object under full control. The ticket was raised using a simplified example. I am providing an API and consumers may pass Path objects which may work or not dependent on how the passed object got created and the used Python version. Before the implemented change it was easier to consume the object and it was actually less code :)

[barneygale]

I'm going to close this as "not planned". I know it's annoying to be in this situation, but you were relying on behaviour in resolve() / realpath() that was inconsistent not only with coreutils realpath, but also with basically any API that accepts POSIX paths, where file1.txt/../file2.txt should error with ENOTDIR. The situation is different on Windows, but that's just one of those things.

If you want to retrieve the parent directory of __file__, use path.parent rather than joining .. and calling resolve().

[barneygale]

If you encountered this problem in an open source project, feel free to point me towards it and I'll try to make a more specific suggestion for how you can replace the resolve() stuff.