Repository navigation
Deprecate register_adapter() and register_converter() in sqlite3 #70838
Description
| BPO | 26651 |
|---|---|
| Nosy | @malemburg, @rhettinger, @ethanfurman, @berkerpeksag, @erlend-aasland, @iafisher, @Strongbeard |
| Files |
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:
assignee = None
closed_at = None
created_at = <Date 2016-03-27.16:57:46.141>
labels = ['extension-modules', 'type-feature', '3.11']
title = 'Deprecate register_adapter() and register_converter() in sqlite3'
updated_at = <Date 2021-11-21.18:46:22.084>
user = 'https://github.com/berkerpeksag'bugs.python.org fields:
activity = <Date 2021-11-21.18:46:22.084>
actor = 'ethan.furman'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2016-03-27.16:57:46.141>
creator = 'berker.peksag'
dependencies = []
files = ['42309']
hgrepos = []
issue_num = 26651
keywords = ['patch']
message_count = 5.0
messages = ['262525', '262561', '403356', '403385', '406729']
nosy_count = 8.0
nosy_names = ['lemburg', 'rhettinger', 'ghaering', 'ethan.furman', 'berker.peksag', 'erlendaasland', 'iafisher', 'Strongbeard']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue26651'
versions = ['Python 3.11']
Activity
berkerpeksag commentedon Mar 27, 2016
In bpo-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.
[1] ghaering/pysqlite@c819a1e#diff-a31e41a9e523fbbf9e60ba9a31f38efeR159
rhettinger commentedon Mar 28, 2016
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.
malemburg commentedon Oct 7, 2021
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 dbapi2.py 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.
erlend-aasland commentedon Oct 7, 2021
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.
iafisher commentedon Nov 21, 2021
See bpo-45858 for a more limited proposal to only deprecate the default converters.
erlend-aasland commentedon May 18, 2022
Based on this discussion and the discussion over at Discourse, I suggest closing this issue as "wont-implement".
erlend-aasland commentedon May 19, 2022
Closing this in favour of gh-90016.