Just in case it wasn't obvious, it's apingos.fspath() and__fspath__() by sticking a 'v' in front.

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

Just in case it wasn't obvious, it's apingos.fspath() and__fspath__() by sticking a 'v' in front.

In that case, perhapsvfspath is better thanvfs_path (for consistency). It's too late to consider__fs_path__ for clarity ;).

I guessvirtual_path() and__virtual_path__() could work? Might be confused with__path__ though

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

"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.

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

Thanks for the sense check!