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.
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.
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.
