From 06e65c2d4e014bbf1dc0114d4b654505e684f66c Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Sun, 4 Dec 2011 23:08:35 -0500 Subject: marathon doc updating session including a rewrite of unicode paragraphs --- lib/sqlalchemy/dialects/sqlite/pysqlite.py | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) (limited to 'lib/sqlalchemy/dialects/sqlite') diff --git a/lib/sqlalchemy/dialects/sqlite/pysqlite.py b/lib/sqlalchemy/dialects/sqlite/pysqlite.py index c8739f242..ad8d5c6f9 100644 --- a/lib/sqlalchemy/dialects/sqlite/pysqlite.py +++ b/lib/sqlalchemy/dialects/sqlite/pysqlite.py @@ -173,15 +173,14 @@ way. Unicode ------- -In contrast to SQLAlchemy's active handling of date and time types for pysqlite, pysqlite's -default behavior regarding Unicode is that all strings are returned as Python unicode objects -in all cases. So even if the :class:`~sqlalchemy.types.Unicode` type is -*not* used, you will still always receive unicode data back from a result set. It is -**strongly** recommended that you do use the :class:`~sqlalchemy.types.Unicode` type -to represent strings, since it will raise a warning if a non-unicode Python string is -passed from the user application. Mixing the usage of non-unicode objects with returned unicode objects can -quickly create confusion, particularly when using the ORM as internal data is not -always represented by an actual database result string. +The pysqlite driver only returns Python ``unicode`` objects in result sets, never +plain strings, and accommodates ``unicode`` objects within bound parameter +values in all cases. Regardless of the SQLAlchemy string type in use, +string-based result values will by Python ``unicode`` in Python 2. +The :class:`.Unicode` type should still be used to indicate those columns that +require unicode, however, so that non-``unicode`` values passed inadvertently +will emit a warning. Pysqlite will emit an error if a non-``unicode`` string +is passed containing non-ASCII characters. """ -- cgit v1.2.1