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