[patch] Add support for standard sqlite3 module

[ymasuda[at]ethercube.com]

Starting with Python 2.5, SQLite binding was introduced as sqlite3 standard module which is
mostly identical to pysqlite2. The attached diff allows to import sqlite3 instead of pysqlite3
if sys.hexversion is greater than 0x020500a1 (Python 2.5a1).
This integration was tested under tests/runtest.py with #2771 patch.

[Yasushi Masuda]

patch to trunk/django/db/backends/sqlite3/base.py

[Yasushi Masuda]

prepended [patch] to the summary.

[James Bennett]

Maybe a better way to handle this would be what we do with threading -- try to import the 2.5 standard module, and if it tosses an ImportError, catch that and import the pysqlite2 module instead.

[ymasuda[at]ethercube.com]

Then, how about like this:

try:
    try:
        # (*explicitly installed*) pysqlite2 succeeds
        from pysqlite2 import dbapi2 as Database
    except ImportError, e:
        # fallback to sqlite3
        from sqlite3 import dbapi2 as Database
except ImportError, e:
    from django.core.exceptions import ImproperlyConfigured
    raise ImproperlyConfigured, "Error loading module: %s" % e

[Malcolm Tredinnick]

The second approach looks better, although I would rather try to import the standard Python module (sqlite3) first and then fallback. That fits in more with the trend to try to do the right thing first and fallback if we need a backwards-compatiblity feature that is common throughout Python's core.

I need to get a Python 2.5 build done and then I'll get this in.

[ymasuda[at]ethercube.com]

Thanks ubernostrum and mtredinnick for comments.
Here I post a revised version of the patch: using nested try...except, and sqlite3 first then pysqlite2.

[ymasuda[at]ethercube.com]

revised version of the patch

[Malcolm Tredinnick]

(In [3818]) Fixed #2772 -- Made SQLite support work correctly with Python 2.5 standard
module (as well as pysqlite2 for earlier Python versions). Patch from
ymasuda[at]ethercube.com.