Did you read Andy Robinson's case study? He suggested that for certain encodings there may be other things you can do that are more user-friendly than raising an exception, depending on the application. I am proposing to leave this a detail of each specific translation. There may even be translations that do the same

--- Guido van Rossum <guido@CNRI.Reston.VA.US> wrote: thing

except they have a different behavior for untranslatable cases -- e.g. a strict version that raises an exception and a non-strict version that replaces bad characters with '?'. I think this is one of the powers of having an extensible set of encodings.

This would be a desirable option in almost every case. Default is an exception (I want to know my data is not clean), but an option to specify an error character. It is usually a question mark but Mike tells me that some encodings specify the error character to use. Example - I query a Sybase Unicode database containing European accents or Japanese. By default it will give me question marks. If I issue the command 'set char_convert utf8', then I see the lot (as garbage, but never mind). If it always errored whenever a query result contained unexpected data, it would be almost impossible to maintain the database. If I wrote my own codec class for a family of encodings, I'd give it an even wider variety of error-logging options - maybe a mode where it told me where in the file the dodgy characters were. We've already taken the key step by allowing codecs to be separate objects registered at run-time, implemented in either C or Python. This means that once again Python will have the most flexible solution around. - Andy ===== Andy Robinson Robinson Analytics Ltd. ------------------ My opinions are the official policy of Robinson Analytics Ltd. They just vary from day to day. __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com