Gabriel Genellina <gagsl-...@yahoo.com.ar> added the comment: > 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. ---------- nosy: +gagenellina _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4947> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
