Make pathlib extensible

Ideas
101

You’re right about backwards compatibility. Foo. I may have to do the diamond thing!

It’s a frustrating edge case, as os.fsencode() doesn’t do I/O, but does vary by system. It’s the only part of PurePath that does this, and (apart from fspath()) the only os function called.

102

PR up! GH-89812: Add `pathlib._BasePurePath` by barneygale · Pull Request #104810 · python/cpython · GitHub

On naming: AbstractPurePath doesn’t seem right, as the class doesn’t have any abstract methods. And to me, PureLocalPath indicates the presence (rather than absence) of the __fspath__() method! I quite like BasePurePath, LexicalPath, maybe LexicalPurePath. Thoughts?

103

Here’s my current thinking:

image
image1000×520 10.5 KB

  • _BasePurePath is like PurePath, but lacking __fspath__(), __bytes__() and as_uri()
  • _AbstractPath is like _BasePurePath, but adds abstract stat(), open() and iterdir() methods, plus all methods that can be derived (like is_dir(), read_text(), glob()). It will be extended by tarfile.TarPath. If that goes well, we can drop the underscore prefix
  • _BasePath is like _AbstractPath, but it uses os functions to implement stat(), open() and iterdir(). It exists mainly to make _AbstractPath testable.
  • _BasePath is like Path, but lacking some methods like expanduser(), hardlink_to(), etc.

I may omit _BasePath if it doesn’t prove useful enough.