Marc-Andre Lemburg <m...@egenix.com> added the comment:
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. ---------- nosy: +lemburg _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26651> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
