GeezerVison

The test naming is pretty janky. #104829 will help.

Would anyone be willing to review #104829? It blocks this PR. (please and thank you!)

#104829 has landed, so test naming should be much improved! Think this is ready for review again.

I've revised the implementation such that the methods are actually removed from PurePath. This will allow our future AbstractPath class to inherit PurePath, as it should conceptually:

(Contrast this with the earlier proposed hierarchy where PurePath and AbstractPath are siblings.

The methods are moved to a new _PurePathExt class, which is inherited by PurePosixPath, PureWindowsPath and Path.

This change will not be visible to users who try to instantiate PurePath, because they'll always get a PurePosixPath or PureWindowsPath instance back.

It will be visible to users who subclass PurePath, but that has only just become possible in 3.12. As such I think it's worth backporting this into 3.12 for consistency.

Here's a version of the diagram that includes the private _PurePathExt class. The diagram in the post above excluded it in order to show the public view of the class hierarchy.

Just a note that I’m meditating on https://hynek.me/articles/python-subclassing-redux/ and linked articles at the moment and wondering if controlling subclass explosion in pathlib should be a guideline 🙂

Oh I totally agree. I'd prefer to add only pathlib.AbstractPath, but I'm prevented by the fact that PurePath has an __fspath__() method :)

And if I were to do pathlib over again, I'd scrap the *WindowsPath and *PosixPath classes. That could be controlled by an argument to the PurePath initialiser instead. Oh well...

I've converted this back to a draft as I'm still in two minds about how to implement this. It's possible I'll add _AbstractPath into this PR, or close this PR and log another, or something else. Sorry for the noise

Friendship ended with #104810, now #106043 is my best friend.

@barneygale