William D. Colburn added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue16783> > _______________________________________ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16783> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com