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 fromPurePath. This will allow our futureAbstractPath class to inheritPurePath, as it should conceptually:

(Contrast this with theearlier proposed hierarchy wherePurePath andAbstractPath are siblings.

The methods are moved to a new_PurePathExt class, which is inherited byPurePosixPath,PureWindowsPath andPath.

This changewill not be visible to users who try to instantiatePurePath, because they'll always get aPurePosixPath orPureWindowsPath instance back.

Itwill be visible to users who subclassPurePath, 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 onhttps://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 addonlypathlib.AbstractPath, but I'm prevented by the fact thatPurePath 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 thePurePath 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