[Zope3-dev] test errors due to ascii defaultencoding assumption

[Tim Peters]

[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.)

[Dieter Maurer]
> That would be true had Python already different types
> for "text" (unicode) and binary strings and would use these
> consistently.

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
>  UnicodeDecodingErrors.

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.

[Tim Peters]
>> 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.

[Dieter]
> 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
setdefaultencoding()|).

> 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
time).