New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sqlite3: OptimizedUnicode obsolete in Py3k #58129
Comments
Connection.text_factory can be used to control what objects are
However, it always returns Unicode strings now. There's even a 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 --- The user can get bytes if he wants to by saying so explicitly. |
+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. |
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 :
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:
Yeah. Perhaps it would be better as a comment in the code.
My intention was to apply it to 3.3 only. |
New changeset 0fc10a33eb4c by Petri Lehtinen in branch 'default': |
Committed the patch after moving the documentation note to a source code comment instead. Thanks for reviews. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: