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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4