See, this if..then is the main symptom of the
misunderstanding. There is no if-then about having to deal
with encodings.
The basic fact to realize is that:
"there is no such thing as plain-text"
One *always* has to deal with encodings.
However, in tightly bounded environments one may get away a
great deal with letting Python/wxPython/C/gettext/locale do
its thing. Under such circumstances it may appear easier to
use an ANSI build.
The big but comes here: in most cases the "tightly bounded"
environment eventually isn't that tightly bounded. The point
is that one needs to take control of all data sources and
sinks: files, filesystem, network, databases, console,
pipes, ... Some of those will be pre-determined in a
controlled environment (such as the console and the
filesystem). Others are not (network, database).
In other words: we never control the encoding of all sources ...
Karsten
···
On Fri, Dec 21, 2007 at 10:54:05AM +0100, jmf wrote:
The problem
here is not only a wxPython ansi/unicode problem. It lies in the fact, that
if a developper has to use the unicode build, she/he has probably to deal
with all this unicode encoding/decoding struff.
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346