That looks great!
I recommend default implementations for home() and cwd() that either return the vanilla Path or raise a suitable error. Those are related to the environment rather than just a filesystem, so it’s reasonable to assume exotic filesystems won’t have them.
And perhaps also make owner() , group(), symlink_to() and hardlink_to() raise by default, assuming that if they’re not implemented, the filesystem doesn’t support that operation. This would make error messages more consistent for the users of the various classes.
I could also imagine owner() & group() getting a default argument similar to dict.get’s or getattr’s, seeing that they sometimes raise KeyError even on vanilla Path.
AbstractUserPath, on the other hand, look like unnecessary generalization. It seems to have a very specific set of assumptions (none of which hold my use case, FWIW):
- the filesystem stores owner (user/group) information
- directories, links and regular files are treated similarly when creating, moving and deleting them
- listing directory contents doesn’t slow down
stat? (I might be misunderstanding this one)
If those don’t hold, AbstractUserPath could still be used, but it wouldn’t really help.
I suggest writing a few different concrete user paths first, and then seeing what could be simplified (with a superclass or otherwise).
Something like UserFileAttributes looks potentially useful, but I’d rather make it into a good standard stat_result lookalike for “exotic filesystems” that might not have all the data (or might have some extra data).
IMO, a stat result should be an immutable, data-only object that’s very fast to retrieve. Attributes like “user name” only make sense on it if they’re readily available. In general, I’d keep user(), group() etc. as methods.
I hope the post is helpful, even though I’m all talk and no action.