move seems like reasonable default implementation for any kind of path, i.e. subclasses would get it “for free” if they implement the underlying operations (but they could also optimize it for copies within a “filesystem”). It would be sad if it went away.
Similar for methods like rename or replace. Implementing them in the base class could be a good opportunity to ensure various Paths can work well together for users, without unnecessary effort from authors of the subclasses.
Most of the is_* methods marked for removal are simple wrappers around stat(). I don’t think it makes much sense to remove these default implementations if stat() is still required.
Which brings to mind what to do about stat(). It seems that stat_result itself could use a protocol (or generic superclass) – perhaps one with only attributes, not the old tuple-like interface?
Or perhaps another class for with stat-related methods (including is_*, chmod, touch)?
Besides read/write, there’s another split that affects what kind of operations are available/allowed. It might be reasonable to encode this in the type system:
- directory (
glob,walk,iterdir;mkdir;move_intodestination) - data (
open,read_*;write_*) - link (
readlink,lstat)
(For example, importlib.abc.Traversable is essentially ReadablePathBase without links, stat, and some ease-of-life utilities that it could get “for free” by subclassing the base, like glob.)
On the other hand, such a class hierarchy could easily become too complex to be usable.