# Make pathlib extensible

**URL:** <https://discuss.python.org/t/make-pathlib-extensible/3428>\
**Category:** Ideas\
**Created:** [February 24, 2020, 12:15am UTC](https://discuss.python.org/t/make-pathlib-extensible/3428 "2020-02-24T00:15:07Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\
**Post date:** [January 26, 2021, 5:33pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/28 "2021-01-26T17:33:06Z")

</div>

> [@barneygale](#):
>
> With all this done, we end up with a new [AbstractPath] class with the following abstract methods:
> 
> - ‘read’ operations: `stat()` , `owner()` , `group()` , `iterdir()` , `readlink()` , `cwd()` , `home()`
> - ‘create’ operations: `touch()` , `mkdir()` , `symlink_to()` , `hardlink_to()`
> - ‘move’ / ‘delete’ operations: `rename()` , `replace()` , `unlink()` , `rmdir()`
> - other operations: `open()` , `chmod()`

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`](https://docs.python.org/3/library/os.html#os.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.

---

_[View the full topic](https://discuss.python.org/t/make-pathlib-extensible/3428)._