ResourceReader used to have this requirement, Traversable does not. We cannot add a requirement as there might be users not doing this, but we can ask new users to do so.

We should document that FileNotFoundError should be raised if a file is not found, but that it is not guaranteed that it will for all Traversable implementations for compatibility reasons.

After reviewing the PR, I'm not convinced the Traversable methods need any specification about when to raise FileNotFoundError (or other exceptions). Let's flesh out what conditions demand prescribed interfaces.

Okay.

Having a better look at it, I think we should only add this specification to open().

Traversable, by design, makes it totally plausible that open() cannot be performed. It could be a nonexistent path, the Traversable could represent object where open() does not make sense given the underlying implementation (it's something that cannot be read), etc.

If Traversable makes it possible for open() to not work, it should give us a mechanism to handle such situations.
If the only thing I know about an object is that it implements Traversable, how can I use open() in a reliable manner without having my code explode?

This mechanism does not need to be FileNotFoundError. But, in my opinion, it is what probably makes the most sense in this case. Please let me know if you have a different/better idea.

Having a look at the open function (https://docs.python.org/3/library/functions.html#open), it does not define which exceptions might be thrown. Similarly for pathlib.Path.open (https://docs.python.org/3/library/pathlib.html#pathlib.Path.open) and zipfile.Path.open (https://docs.python.org/3/library/zipfile.html#zipfile.Path.open).

And since the canonical implementation of a Traversable resource is those two Path classes, it seems infeasible for the protocol to enforce a specific constraint on the available exceptions.

I think the best this protocol can do is advertise that the underlying implementation may raise an Exception if the target indicated by self cannot be opened (allowing for an Exception where appropriate), but in my opinion, that's the default interface for any protocol (or function) unless otherwise specified.

I don't want to explicitly call out FileNotFoundError or IsADirectoryError because those exceptions happen to be the most common. Consider for example the case where permission is not granted for read:

$ pathlib.Path('./foo').open()
PermissionError: [Errno 13] Permission denied: 'foo'

That's yet another case where Traversable.open might raise something other than FileNotFoundError.

In my opinion, unless the Traversable objects are expected to handle or transform exceptions, it's fine to simply delegate to the underlying implementations and allow any exceptions to bubble through.

That makes sense, I wish all these details were documented, but it is more than enough precedent to choose to not add such enforcements to the specification.