What it should do is be consistent (predictable) in it's handling of
input and output.  If it accepts unicode and outputs unicode, then it
should accept unicode and output unicode, not accept garbage and then
barf.  Valid data should be consistantly valid, and invalid data
should be consistently invalid.   It is bad behavior for a system to
allow invalid data in that can't be recovered or handled.

On Sun, Dec 30, 2012 at 9:32 AM, Ezio Melotti <report@bugs.python.org> wrote:
>
> Ezio Melotti added the comment:
>
>> Treating invalid data as sometimes valid and sometime as invalid is a problem.
>
> What is valid is defined by your application.  AFAIU sqlite3 defaults to utf-8, but it's able to work with latin1 data as well.  The fact that you are mixing utf-8 and latin1 is an error in your application, and while it might be nice if sqlite3 warned you about it, it's not necessarily its responsibility.  Even thought it's a really bad idea, you might want to store data with different encodings and still being able to retrieve them using the right text_factory.
>
> However while trying to reproduce the issue I noticed a possible inconsistency and reported it on #6010.
>
> ----------
> stage:  -> committed/rejected
> superseder:  -> unable to retrieve latin-1 encoded data from sqlite3
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue16783>
> _______________________________________