[Python-ideas] Official MySQL module

[Dustin J. Mitchell]

On Thu, Mar 7, 2013 at 4:16 PM, David Mertz <mertz at gnosis.cx> wrote:
> I disagree moderately with Dustin.  Obviously, it is true that a magic wand
> doesn't produce a standard-library module.  However, having support for
> MySQL/MariaDB (and PostgreSQL) in the standard library would be desirable.
> This would bring MySQL support to the same level as we have for SQLite3.

Having a simple database engine in the stdlib is helpful -- it means
that apps like Buildbot can use a database without requiring users to
set up MySQL or Postgres.  I think the Python community is actually
better served by having an ecosystem of competing DBAPI
implementations for other databases.  If the stdlib blesses one, then
there's very little point in the others continuing to exist.  Would
that be Python-MySQL (which is somewhat heavy and requires MySQL
libraries, and judging from the sourceforge page the project is
moribund and rudderless) or PyMySQL (which, much as I love it, is
somewhat less performant, probably buggier, and still lacks some
things you'd want for production use, like SO_KEEPALIVE).

> In particular, I would NOT WANT such standard library support to include any
> ORM layer to it; I feel like those should remain as third-party tools (and
> compete on their various merits).  But the basic level of providing a
> *binding* feels like something desirable (and specifically, a binding that
> was as close to a drop-in substitute for 'sqlite3' as possible).

I didn't say anything about an ORM!

SQLAlchemy has a fantastic query-formulation layer ("core") that
manages to work around idiosyncracies with the various DBAPI
implementations out there, while not trying to map any objects or
relations.  And as Guido says, any implementation -- in or out of the
stdlib -- is based on PEP249.  SQLAlchemy just wraps that with some
syntax and compatibility hacks.  Here's the list of supported
dialects:
  http://docs.sqlalchemy.org/en/rel_0_8/dialects/

Dustin