Antoine Pitrou writes: > Perhaps you are speaking with your emacs hat, where the purpose is > to output to the same file that serves as input.
No, I'm not wearing my Emacs hat. If I was, there would be no problem. You just use binary for most such purposes. Historically that was how even Emacs worked under X: you did input and output to files in an 8-bit clean way, then picked your screen font to correspond to your preferred encoding. Of course that's assuming an 8-bit encoding, but historically Emacs couldn't do anything useful with multibyte coding systems. > But most applications do not work in that manner. They take some > input and optionally produce an output in an entirely different > format (an other file format, or some database requests, or some > visual feedback, etc.). Therefore both "encodings" are > decorrelated. I concede that I have no better statistics on the matter than you do, but I think that's wishful thinking. It is quite common for "pure output" to be mixed with "echoed input", for example. Even if a file is converted to another format (eg, restructured text to LaTeX), it's very common for the text encoding to be preserved. "Visual feedback" related to text files typically includes fragments of the text. And so on. Of course it is possible to give examples where they can be decorrelated. But examples that support Michael's position are harder to come by than you seem to think. For example: > If I'm reading a configuration file the encoding of the > configuration file will not decide which charset my dynamic HTML > pages are using. But it *does* determine the charset of ErrorDocuments displayed by Apache. Users are likely to get somewhat confused if the ErrorDocuments are in a different charset from your dynamic HTML. You just can't get away from the need for explicit management of codecs if you want a robust internationalized application. I don't object to giving users an easy way to get the behavior Michael proposes; it just should not be the *default*. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
