Logged In: YES 
user_id=442849

Ah.. ok.. some examples:

I'm writing Web-Applications using CGI or FastCGI. The
webserver will pass user input as plain strings but within
my program I want to use plain strings as little as possible
to avoid all kinds of problems with diacritical characters
(foremost umlauts and the EUR symbol). The websites the CGI
scripts are used with usually have one charset for all
pages. But some sites use iso-8859-1 and some use utf-8 and
I don't want to modify my scripts to fit the charset of the
site. Rather I'd like to  use Apache's SetEnv directive to
tell my scripts what charset their input is going to be in.
Yes, I know, there are other ways to handle this :-)

I keep using XIST for html output
(http://www.livinglogic.de/Python). XIST tries to avoid
using the default encoding, probably in the light of it
being depricated. But it does not avoid it completely. There
are a number of subtle cases in which it still depends on it
and in all these cases I run into run-time errors which can
be avoided in a snap by 
setting the default encoding to what my actual default
encoding is.
I use XIST with Zope and FastCGI, running several instances
of the same interpreter on the same machine, with different
default encodings each (mostly utf-8, but some iso-8859-1,
which I can't just convert).

My own OSS project orm (http://t4w.de/orm) carefully
seperates the database's and the application's charset but
uses Python's default encoding as the default for each and
every setting. Those settings need to be set explicitly if
the default encoding does not match the encoding actually
used, cluttering the sourcecode and making maintaince more
difficult. I use orm in connection with all the above cases.