GH-128520: pathlib ABCs: add JoinablePath.__vfspath__()

[barneygale]

In the abstract interface of JoinablePath, replace __str__() with __vfspath__(). This frees user implementations of JoinablePath to implement __str__() however they like (or not at all.)

Also add pathlib._os.vfspath(), which calls __fspath__() or __vfspath__(). This will be exported as a public function in the pathlib-abc PyPI package.

Some related discussion here: https://discuss.python.org/t/protocol-for-virtual-filesystem-paths/82753

• Issue: Make pathlib ABCs usable by zipfile.Path #128520

[jaraco]

This sounds like the right solution for decoupling the use of __str__ for casual user use and for the specific API purpose required by JoinablePath. I don't love the name vfspath. If that's the phrasing, I like to see at least vfs_path (separate the two terms). Even better would be to come up with a name that's a single word (__moniker__, __location__, __traversal__, ...), but I'm not coming up right now with any word I love. Regardless, I'll be happy with whatever property name you settle on.

[barneygale]

Just in case it wasn't obvious, it's aping os.fspath() and __fspath__() by sticking a 'v' in front.

That said, I don't love it either! :P

[jaraco]

Just in case it wasn't obvious, it's aping os.fspath() and __fspath__() by sticking a 'v' in front.

In that case, perhaps vfspath is better than vfs_path (for consistency). It's too late to consider __fs_path__ for clarity ;).

[barneygale]

I guess virtual_path() and __virtual_path__() could work? Might be confused with __path__ though

[barneygale]

Thanks for the review btw, much appreciated! I'll wait to see what Petr thinks before I go any further. I should add Mr Moore too, actually

[pfmoore]

"Mr. Moore" - how grand 🙂 (If it's because you didn't know my first name, it's Paul 👋).

This seems like a reasonable enough change, and I agree with the basic idea that we should separate "the string representation" from "the representation as a path string". It's a very subtle distinction, though, and I think that before we can expect users to work with the new API, it'll need some pretty good documentation. I'm happy to defer that for now, but I don't think we can say user-defined path subclasses are ready for general use without it.

In practical terms, this feels like a small step, with a lot of compatibility and design questions to follow, but I'm fine with a small starting step.

[encukou]

Looks good on a cursory look.
I don't think I'll get to do an in-depth review soon.

[barneygale]

Thanks for the sense check!