[Python-Dev] Relaxing Unicode error handling

[M.-A. Lemburg]

Guido van Rossum wrote:
> Sure.  So in your programs, keep the default.
> 
> But if someone has written a program and decides that they don't want
> to deal with their (*their*!) errors by fixing the code, but rather
> would continue to go with possibly broken data (and they may well know
> enough about their application to know that that is harmless), why
> should we not give them a way to do that?
> 
> AFAIK all the proposal does is give a way to change the default error
> handling -- any code that sets an explicit error handling policy will
> continue to receive exceptions.

Note that the default error handling is defined by the codec,
not the Unicode implementation. In most cases, the implementation
passes NULL as errors argument to the codec which means that
the codec's default errors handling should be used (for builtin
codecs this happens to be the same as "strict", but it is
explicitely allowed for codecs to decide what to do, so
external codecs might want to be less restrictive or do
something clever instead, e.g. use approximations of the
characters in question).

There are only a few places where the implementation does use
"strict" to prevent cases where the automagic coercion code
tries to convert an 8-bit string into Unicode, or Unicode into
a default encoded 8-bit string. The only "default error handling"
the proposed option could change is this usage of "strict".

IMO, an application which relies on silencing these kinds of
errors is simply broken.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 05 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::