Database engine bindings for Python (was: Database statements via python but database left intact)

[Roy Smith]

In article <mailman.781.1381066683.18130.python-list at python.org>,
 Chris Angelico <rosuav at gmail.com> wrote:

> I would hope that an absence of libpq could simply result in a
> courteous exception when the module's imported, but maybe that'd be
> hard to implement.

It works fine.  I've had this in production for a while:

# Psycopg2 is only needed for a single hacky lookup which only happens
# in the station details admin tool.  Installing it has compicated
# dependencies, so don't worry if it's not there.
try:
    import psycopg2
except ImportError:
    psycopg2 = None

[...]

        if psycopg2 is None:
            logger.warning("psycopg2 not installed")
            return None

That being said, I agree that Postgres support does not belong in the 
core product.  Nor does MySQL, or Oracle, or SqlServer, or MongoDB, or 
CouchDB, or Cassandra, or a zillion other databases.  There's a few 
reasons.

One (as several people have already mentioned), it bulks up, and 
complicates, the release process.

The other is that once something is in the core distribution, it become 
the de-facto "right way" to do something, whether it's the best or not.  
>From my own experience, I resisted trying nose for quite a while because 
unittest was baked in and it was "good enough".  Ditto for requests vs. 
urllib.

And finally, with something like a database driver, you really don't 
want your release schedule to be tied to the language.  If the postgres 
folks come out with a new database feature (or bug fix) which requires a 
change to the driver, they should be able to release the new driver on 
their own schedule.