One thought - how does all of this affect os.PathLike and friends? The __fspath__ method is defined as returning str or bytes, and it should return “the file system path representation of the object”. A Path subclass that represents (say) a member of a zip archive can’t really do this, particularly as the user expectation is that os.fspath(path) will return something that could reasonably be passed to an external utility (such as the user’s editor).
Maybe I missed some discussion on this - can _PathBase subclasses opt out of being PathLike? I wonder if they should be “not PathLike” by default, and have to explicitly opt into being convertible to a filesystem path.
Sorry if this is something you’ve already thought about - I’m not sure where I could look to check.
It’s a very good thought, and was briefly covered earlier (easy to miss in this long thread):
pathlib._PathBase won’t be os.PathLike by default for all the reasons you mentioned. It would be a catastrophe if open(ZipPath('README.rst', zipfile=blah)) silently opened a file called README.rst on the local filesystem.
Cool, thanks. I’d imagined ZipPath returning something like /.../archive.zip/README.rst (the way zip files appear in the import system) so using it would be wrong, rather than disastrous, but what you’ve done is better
I’ve been considering backporting and publishing the latest pathlib as a standalone PyPI package (compatible with 3.8+), so that other PyPI packages like dohq-artifactory can make use of the new _PathBase ABC and validate its design. Previously I was planning to backport all of pathlib, but it’s rather more work than I was expecting, so I’m now looking at backporting _PurePathBase and _PathBase only.
I’ve played around with possible values for _PurePathBase.pathmod and how we support customization of low-level path syntax. The right answer still isn’t clear to me, but I think setting it to posixpath is a good first guess. I’ll make a PR for that once GH-110670 lands, and then move on to the PyPI package.
Thanks to everyone following along and being encouraging, it means a lot
What’s the reason for this? Did you want the backported classes to be subclasses of the standard library classes (or isinstance(pathlib_backport.Path(), pathlib.Path) == True?
If you drop a link to the repo, I’d be happy to look at the code for answers.
Pathlib relies on new features elsewhere in the standard library - for example glob.translate(), os.path.splitroot() and os.path.realpath(strict=True). It’s the realpath() implementations in ntpath and posixpath that scared me off - they might not be easy to backport.
I wouldn’t mind if someone else does a complete backport, but I reckon my PyPI package will be just the ABCs, at least initially.
November 2023 progress report