[Python-Dev] PEP 293, Codec Error Handling Callbacks

[Oren Tirosh]

On Tue, Aug 06, 2002 at 10:25:34AM +0200, Martin v. Loewis wrote:
> > 2. Keep the old, limited functionality, let it fail, catch the error,
> > re-use an argument originally intended for an error handling strategy to 
> > shoehorn a callback that can implement the missing functionality, add a new 
> > name-based registry to overcome the fact that the argument must be a string.
> 
> That is possible, but inefficient. 

I'm confused.

I have just described what PEP 293 is proposing and you say that it's 
inefficient :-? I find it hard to believe that this is what you relly meant 
since you are presumably in favor of this PEP in its current form. 

I can't tell if we actually disagree because apparently we don't 
understand each other.

> > Since this approach is conceptually stuck on treating it as an error it 
> > actually creates and discards a new exception object for each character 
> > converted via this path.
> 
> It's worth: If you find that the entire string cannot be encoded, you
> have typically two choices:
...

Instead of treating it as a problem ("the string cannot be encoded") and 
getting trapped in the mindset of error handling I suggest approaching it 
from a positive point of view: "how can I make the encoding work the
way I want it to work?".  Let's leave the error handling for real errors.

Treating this as an error-handling issue was so counter-intuitive to me 
that until recently I never bothered to read PEP 293. The title made me 
think that it's completely irrelevant to my needs. After all, what I 
wanted was to translate HTML to/from Unicode, not find a better way to 
handle errors.

	Oren