Well, but we think it's pretty clear.  The glossary entry says file object interfaces are defined by the classes in the io module.  As do the io module docs.  Perhaps the first sentence of the io docs could be modified to strengthen that (but it already does link to the glossary entry which is explicit that the io module defines the interfaces).

On the other hand, your statement that "few or no other assumptions are made" is, while not accurate, not *wrong*, in the following sense:  *if* a standard library module depends on file attributes and methods, then it expects them to conform to the io module interfaces.  If it does not depend on a particular part of the API, then a duck type class doesn't actually have to implement that API in order to work with that standard library module.  Of course, we might change what elements of the file API are depended on, but hopefully we only do that kind of change in a feature release.  I'm sure we have made such changes while fixing bugs, though, so if you want to be *sure* of forward compatibility, you should indeed implement the full io-specified interface in your file-like class.  Which is one reason the ABCs provide default implementations for most of the methods.  It makes it really easy to build a future-proofed duck type.