Perhaps I'm just bad at searching for bugs, but anyhow, I wanted to know what you all thought about the following behavior.
A quick search of pydev archives yielded a nice wrapper to apply to streams to perform decoding and encoding behind the scenes. Assuming I get the correct encodings from somewhere (that's a whole 'nother thread): Here's the docs: EncodedFile( file, input[, output[, errors]]) Return a wrapped version of file which provides transparent encoding translation. Strings written to the wrapped file are interpreted according to the given input encoding and then written to the original file as strings using the output encoding. The intermediate encoding will usually be Unicode but depends on the specified codecs. If output is not given, it defaults to input. errors may be given to define the error handling. It defaults to 'strict', which causes ValueError to be raised in case an encoding error occurs. Base on that, I wrote the following code at startup: sys.stdout = codecs.EncodedFile(sys.stdout, 'latin-1', 'cp437') sys.stdin = codecs.EncodedFile(sys.stdin, 'cp437', 'latin-1') Now my application never returns from its first call to sys.stdin.readline. It turns out to be troublesome for my case because the EncodedFile object translates calls to readline into calls to read. I believe it ought to raise a NotImplemented exception when readline is called. As it is it silently causes interactive applications to apparently hang forever, and breaks the line-buffering expectation of non-interactive applications. If raising the exception is too much to ask, then at least it should be documented better. -- Neil Cerutti The choir invites any member of the congregation who enjoys sinning to join the choir. --Church Bulletin Blooper -- http://mail.python.org/mailman/listinfo/python-list
