> It probably uses sys.getdefaultencoding() instead.

That would be wrong too, according to the cited documentation.

file.encoding is a read only attribute; it can be set in C code using 
PyFile_SetEncoding. Apart from its definition in fileobject.c, it is 
*only* used by PyInitialize when sys.stdin/stdout/stderr are created. 
There are no tests, nor any other use of it anywhere. Apparently the 
attribute *is* checked when writing unicode objects, but it does not 
work.

I'm guessing now, but probably the original intent was to make file 
objects behave like the wrapper returned by codecs.open works now -- 
later it was deemed impractical and forgotten. Now, the "declarative" 
meaning of file.encoding survives, but the "behavior" is broken.

I don't know what would be the right thing to do. The encoding used by 
stdin/stdout/stderr is valuable information so the attribute should 
remain. Fixing the behavior is like having a crippled 
StreamReaderWriter and I don't see the point. But StreamReaderWriter 
has an "encoding" attribute too, and it "works", so one cannot rely on 
having such attribute to know whether the stream automatically encodes 
its data or not.