> 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.
Please try to categorize Python applications. My bet is that the majority of Python applications written today do "web" stuff. In the web, input encoding and output encoding are fairly decorrelated - in particular for databases and files read from disk. > 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*. An easy way is pointless if it's not the default. The "complicated" way is to pass a parameter indicating what encoding you want to use. It's complicated not because it's difficult to use, but because you first need to grasp this entire unicode stuff. So if the easy way wasn't the default, you are lost with the error message you get, and the only word you recognize in it is "unicode", which is, as far as you know, a synonym for "hell". Regards, Martin _______________________________________________ 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
