homepage

Connection.text_factory can be used to control what objects are
returned for the TEXT data type. An excerpt from the docs:
 For efficiency reasons, there’s also a way to return str
 objects only for non-ASCII data, and bytes otherwise. To
 activate it, set this attribute to sqlite3.OptimizedUnicode.
However, it always returns Unicode strings now. There's even a
test for this feature which is obviously wrong:
 def CheckOptimizedUnicode(self):
 self.con.text_factory = sqlite.OptimizedUnicode
 austria = "Österreich"
 germany = "Deutchland"
 a_row = self.con.execute("select ?", (austria,)).fetchone()
 d_row = self.con.execute("select ?", (germany,)).fetchone()
 self.assertTrue(type(a_row[0]) == str, "type of non-ASCII row must be str")
 self.assertTrue(type(d_row[0]) == str, "type of ASCII-only row must be str")
It checks for str in both cases even though it should test for
bytes in the latter case.
---
The user can get bytes if he wants to by saying so explicitly.
Having the library mix bytes and unicode by itself makes it
harder for the user. Furthermore, I don't really buy
the "efficiency" reason here, so I'd vote for removing the whole
OptimizeUnicode thing. It has never worked for Py3k so it would
be safe.

+1 for removing, it makes no sense under Python 3.

Attached a patch. It changes OptimizedUnicode to be an alias for PyUnicode_Type and adds a note to the documentation for porters from 2.x that it has no effect on py3k.
The patch removes/refactors all OptimizedUnicode and allow_8bit_chars related obsolete code that had been left over from py3k transition. These removals/refactorizations have no operational effect, so the module still works the same way it has always worked in Py3k.
Should OptimizedUnicode be deprecated, too? In this case, it cannot be aliased to str, and _pysqlite_fetch_one_row() needs to raise a DeprecationWarning if OptimizedUnicode is used.

> Should OptimizedUnicode be deprecated, too?
I'd say just undocument it.

> > Should OptimizedUnicode be deprecated, too?
> 
> I'd say just undocument it.
Even remove the note from the patch?

Le jeudi 02 février 2012 à 16:43 +0000, Petri Lehtinen a écrit :
> Petri Lehtinen <petri@digip.org> added the comment:
> 
> > > Should OptimizedUnicode be deprecated, too?
> > 
> > I'd say just undocument it.
> 
> Even remove the note from the patch?
Well, I guess keeping the note is fine.

I’m not sure the doc note is useful, but didn’t code search to confirm it.
Also, 3.2 may be out of bounds for this cleanup (I don’t know the rules for what can be committed in what branches these days).

Éric Araujo wrote:
> I’m not sure the doc note is useful, but didn’t code search to
> confirm it.
Yeah. Perhaps it would be better as a comment in the code.
> Also, 3.2 may be out of bounds for this cleanup (I don’t know the
> rules for what can be committed in what branches these days).
My intention was to apply it to 3.3 only.

New changeset 0fc10a33eb4c by Petri Lehtinen in branch 'default':
Undocument and clean up sqlite3.OptimizedUnicode
http://hg.python.org/cpython/rev/0fc10a33eb4c 

Committed the patch after moving the documentation note to a source code comment instead. Thanks for reviews.