Aw: Re: PEP 249 Compliant error handling

[Karsten Hilbert]

> That's certainly a possibility, if that behavior conforms to the DB API "standards". My concern in this front is that in my experience working with other PEP 249 modules (specifically psycopg2), I'm pretty sure that columns designated as type VARCHAR or TEXT are returned as strings (unicode in python 2, although that may have been a setting I used), not bytes. The other complication here is that the 4D database doesn't use the UTF-8 encoding typically found, but rather UTF-16LE, and I don't know how well this is documented. So not only is the bytes representation completely unintelligible for human consumption, I'm not sure the average end-user would know what decoding to use.
> 
> In the end though, the main thing in my mind is to maintain "standards" compatibility - I don't want to be returning bytes if all other DB API modules return strings, or visa-versa for that matter. There may be some flexibility there, but as much as possible I want to conform to the majority/standard/whatever


The thing here is that you don't want to return data AS IF it was correct despite it having been
"corrected" by some driver logic.

What might be interesting to users is to set an attribute on the cursor, say,

   cursor.faulty_data = unicode(faulty_data, errors='replace')

or some such in order to improve error messages to the end user.

Karsten