The implementation of os.path.relpath accesses the filesystem making the two paths absolute and then calculating the common path, using that function to implement a PurePath method is wrong becase it should work without the any file or directory being there (its definition is "Base class for manipulating paths without I/O"), the use case that it breaks is when we don't have files on disk for example I use it to create the structure of a zip archive.

Removing tests is not a good idea.

Mixing relative and absolute paths should raise an exception as you stated and should be fixed.

I didn't remove any tests. Please share an example of where this breaks.

I told a lie - I actually did remove two assertions that supply strings to the method. Will fix!

I thought that os.path.relpath accessed the filesystem, but taking a better look at it I guess it doesn't.

I don't have a Windows machine and I can't provide a concrete example, I'm sorry, anyway it calls os.path.abspath and following the chain we arrive at a Windows api callGetFullPathNameW, that's where I expect PurePath to break because it should be platform independent and this change would make it depend on the result of a winapi call.
Can you test it with names and characters that are reserved on Windows but are allowed on Posix-systems?

I would have just tweaked the fail condition to make sure that we raise the exception for the bug you noticed.

👍 thanks, I'll try that out!

It's true thatrelpath() can callos.getcwd(). However, the working directory only contributes to the resultif we pass one relative path and one absolute. And that's specifically disallowed in pathlib'srelative_to(). In other cases, the two matching prefixes cancel eachother out incommonpath().

The fact thatrelpath() needlessly callsabspath() when given two relative paths is regrettable, and probably worth fixing. But it shouldn't have an observable effect here. I'll try to find a counterexample.

It's not just getcwd, for example "c:" is a valid filename on Linux: on Windows after abspath you would get the current directory on the C drive while on Linux it's the file named "c:" in the current working directory so the calculations that follow would be wrong, there are also reserved names on Windows like COM or CON and characters that are not allowed.

I don't think that matters -os.getcwd() can return something totally nonsensical and we wouldn't care, as long as it returns the same thing twice in a row, so that the shared prefix can be eliminated. Right?

You're referencingos.getcwd() because you're looking at the implementation ofos.path.abspath inos.posixpath but on Windowsos.path resolves toos.ntpath and in that moduleos.path.abspath calls_getfullpathname() that calls the windows api.

Again, I don't think it matters. If you think it does, could you please provide a reproduction case. Thank you.

I've logged#99199 to coverrelpath() needlessly callingabspath() when the paths' anchors match.

Turns out there's another incompatibility related to leading../ segments - see#99199 (comment)

I've revised the implementation to not userelpath() :)

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again.

Thanks for making the requested changes!

@brettcannon: please review the changes made to this pull request.

Thanks!

Thank you!