The files()/Traversable api is meant to replace ResourceReader api, but it falls short in one dimension, tying the abstraction to a file system path.

I propose to document that Traversable users *should* implement __fspath__ if the Traversable represents a file-system path.

This will essentially make os.fspath(importlib.resources.files(module) / resource) the equivalent of importlib.resources.path(module, resource), for which currently there is no replacement using files().

I am gonna wait until/if GH-26272 (#44196) gets merged because this would conflict with that.

The problem with the `__fspath__` protocol is that it assumes a file system. The `importlib.resources` and `Traversable` protocols are trying to provide a lower-level interface that doesn't assume a file system. Fortunately, there already exists a helper function `as_file` (https://docs.python.org/3/library/importlib.html#importlib.resources.as_file) that's meant to provide the user experience that `path` once provided, but for Traversable files.

Does that satisfy the need you've identified?

That's why I said it should be optional. If the object can implement it, it should. `pathlib.Path` certainly can, `zipfile.Path` can't, and that's alright.
If the Traversable does not represent a path on the file-system, it does not make sense to implement `__fspath__`, so it shouldn't.

I think `as_file` should learn to behave like `path`, if `__fspath__` is available, it will use that path, otherwise it will do what it does currently, which is creating a temporary path and writing the resource contents there.

> I think `as_file` should learn to behave like `path`, if `__fspath__` is available, it will use that path.

Oh, that's an interesting idea. And that's effectively what happens [here](https://github.com/python/importlib_resources/blob/1886e2b9d699c55afc1b75dc19e7026ad27e453a/importlib_resources/_common.py#L109), where `as_file` returns a native Path object if that's what it encounters. Maybe another dispatcher could accept `os.PathLike` and in that case, return `pathlib.Path(os.fspath(path))`.

Only thing is, that code would serve no purpose until there existed at least one other resource provider besides FileReader that has file-system-local resources. I'm not aware of any such provider.

CompatibilityFiles would use this. We could add a dispatch for that too, but that's 2 different cases now and `os.PathLike` would be able to handle both.