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.

Title: Deprecate register_adapter() and register_converter() in sqlite3
Type: enhancement Stage: patch review
Components: Extension Modules Versions: Python 3.11
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Strongbeard, berker.peksag, erlendaasland, ethan.furman, ghaering, iafisher, lemburg, rhettinger
Priority: normal Keywords: patch

Created on 2016-03-27 16:57 by berker.peksag, last changed 2022-04-11 14:58 by admin.

File name Uploaded Description Edit
deprecate_adapters.diff berker.peksag, 2016-03-27 16:57 review
Messages (5)
msg262525 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-03-27 16:57
In issue 19065:

Gerhard says:

"I'm -1 because I believe that ultimately, adapters and converters were a mistake to add to pysqlite. That's why I deprecated them in pysqlite 2.8.0."

Here is a patch (based on commit from pysqlite project [1]) to deprecate them.

msg262561 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-03-28 06:27
A few thoughts: 1) Deprecation messages should say "do X instead" rather than leaving users stranded.  2)  As long as most of our users are still with Python 2.7 we need to avoid deprecations that present obstacles to Python 3 adoption or that increase transition costs.  3)  The adapters have been around for many years; the older the API, the more people people will have come to rely on it.  4) The standard library is expected to be less changeable than third-party modules (we say that the standard library is where code goes to die and it should already be dead on arrival so that the word "standard" has more meaning.
msg403356 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2021-10-07 07:48
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.
msg403385 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-10-07 11:02
Yes, deprecating the preconfigured adapters and converters, but keeping the ability to register adapters/converters sounds like a very good idea to me. As you point out, Marc-Andre, they are application specific. Also, implementing converters and adapters is very trivial.

In any case, the documentation for registering converters should be improved, IMHO.
msg406729 - (view) Author: Ian Fisher (iafisher) * Date: 2021-11-21 16:47
See bpo-45858 for a more limited proposal to only deprecate the default converters.
Date User Action Args
2022-04-11 14:58:29adminsetgithub: 70838
2021-11-21 18:46:22ethan.furmansetnosy: + ethan.furman
2021-11-21 16:47:47iafishersetmessages: + msg406729
2021-11-11 14:29:59Strongbeardsetnosy: + Strongbeard
2021-10-07 11:21:03erlendaaslandsetversions: + Python 3.11, - Python 3.6
2021-10-07 11:07:09iafishersetnosy: + iafisher
2021-10-07 11:02:24erlendaaslandsetnosy: + erlendaasland
messages: + msg403385
2021-10-07 07:48:23lemburgsetnosy: + lemburg
messages: + msg403356
2016-03-28 06:27:03rhettingersetnosy: + rhettinger
messages: + msg262561
2016-03-27 16:57:46berker.peksagcreate