[not Tim Peters; this part was written by Fredrik Lundh, and
got misattributed in the reply]
>> When the Unicode type was added, people disagreed on what the
>> [default] encoding should be (ASCII, ISO-8859-1, or UTF-8), so the
>> setdefaultencoding hook was added so we could play with it.
>> Unfortunately, nobody got around to remove it before the release.
>> (to me, arguing that it's a good thing that you can use a global setting
>> to control what a+b does when a is an 8-bit string and b is a unicode
>> string is about as silly as arguing that it would be a good thing to have
>> a global setting for controlling what a+b does if a is an integer and b is
>> a string. if you want to convert between different logical types (encoded
>> data and text are different things), use an explicit conversion.)
> That would be true had Python already different types
> for "text" (unicode) and binary strings and would use these
That's the plan, yes.
> Nowadays, life is hell without a sensible "setdefaultencoding":
> Many isolated modules intersperse unicode in an otherwise
> "string" dominated world causing wide spread
And setdefaultencoding helps that? What, you set it to latin1 just to
squash the exceptions? "Brrrrr", if so. I suppose that's got a
decent shot at working by accident, anyway.
>> I'm sure sys.setdefaultencoding will vanish in a future Python
>> release, since it wasn't intended to persist beyond initial
>> development to begin with.
> Hopefully only after Python cleaned up the separation
> between text and binary strings.
FWIW, I don't expect this before Python 3.0 (where by "this" I mean
both having distinct text and binary string types, and losing
> Otherwise, I would be forced to maintain my private Python
> version (with "setdefaultencoding").
Not that this is worth worrying about ;-), you could just stick to
using Python 2.4.2 (or whichever stable version was current at the
Zope3-dev mailing list