[Python-Dev] PEP 293, Codec Error Handling Callbacks
Tue, 06 Aug 2002 09:36:40 +0200
Jack Jansen wrote:
> On maandag, augustus 5, 2002, at 05:47 , M.-A. Lemburg wrote:
>> Jack Jansen wrote:
>>> Having to register the error handler first and then finding it by
>>> name smells like a very big hack to me. I understand the reasoning
>>> (that you don't want to modify the API of a gazillion C routines to
>>> add an error object argument) but it still seems like a hack....
>> Well, in that case, you would have to call the whole codec registry
>> a hack ;-)
> No, not really. For codecs I think that there needn't be much of a
> connection between the codec-supplier and the codec-user. Conceivably
> the encoding-identifying string being passed to encode() could even have
> been read from a data file or something.
> For error handling this is silly: the code calling encode() or decode()
> will know how it wants errors handled. And if you argue that it isn't
> really error handling but an extension to the encoding name then maybe
> it should be treated as such (by appending it to the codec name in the
> string, as in "ascii;xmlentitydefs" or so?).
You are omitting the fact, though, that different codecs may need
different implementations of a specific error handler. Now the
error handler will always implement the same logic, so to the users
it's all the same thing. And by using the string alias he needn't
worry about where to get the error handler from (it typically
lives with the codec itself).
Note that error handling is not really an extension to the encoding
itself. It just happens that it can be put to use that way for
e.g. escaping non-representable characters. Other applications
like fetching extra information from a external sources or logging
the positions of coding problems do not fall into this category.
CEO eGenix.com Software GmbH
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/