This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients berker.peksag, ghaering, lemburg, rhettinger
Date 2021-10-07.07:48:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
FWIW: I'm -1 on removing the possibility to register conversion or adapter hooks in sqlite3. Such mechanisms have become a standard with Python database modules and are widely used to adapt them to applications or middleware using the modules.

The database module defaults don't always work well everywhere and there needs to be an efficient way to modify this behavior. Fixing all input to .execute() et al. and all output from .fetch*() is not efficient.

I'd suggest to close this as rejected. The deprecation won't do anyone good.

Related to the few such implementations in of sqlite2, which I believe triggered this issue:

Those are not necessarily ideal, since they don't handle all possible cases.

The adapters (conversion from Python data type to SQLite data type) are always used, but the converters (conversion from SQLite data type to Python type) are not, since those rely on SQLite providing type information, which it only does if you pass in detect_types to the .connect() method. Many people don't notice the missing time offset support in the converters due to this (sqlite3 returns strings instead).

Modifying those preconfigured adapters / converters would need to be a separate issue, though. E.g. deprecating the date/timestamp converters would be a way forward, since applications will know better what to do in their particular use case. Such a deprecation would have to take a longer while, though, for the reasons stated by Raymond.
Date User Action Args
2021-10-07 07:48:23lemburgsetrecipients: + lemburg, rhettinger, ghaering, berker.peksag
2021-10-07 07:48:23lemburgsetmessageid: <>
2021-10-07 07:48:23lemburglinkissue26651 messages
2021-10-07 07:48:22lemburgcreate