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

[Chris Angelico]

On Sun, Oct 6, 2013 at 8:10 PM, Chris “Kwpolska” Warrick
<kwpolska at gmail.com> wrote:
> It would require Postgres around people’s (or at least packagers’)
> systems, and it often gets messy when we have such requirements.

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.

> Also, Postgres is much harder to configure than MySQL,
> especially if you have no experience or an asshole OS.

You can get a ready-to-go Postgres under Debian by simply apt-getting
it. The default config might not give you optimum performance, but
it'll work just fine. Most people shouldn't need to dig into the
configs of _any_ database before getting the app going -
out-of-the-box settings should be fine for early development, even
deployment if you're not doing a lot of traffic.

> Moreover, the stdlib is where packages come to die.

Fair point. That is an issue.

> We should also educate people on how PostgreSQL works with a nice,
> human-friendly tutorial.  Especially in some non-standard things and
> things that differ between PostgreSQL and MySQL — like how to make an
> auto-incrementing ID field (use sequences), or how PostgreSQL arrays
> work, among others.  The wiki (that nobody reads anyways) could also
> use some marketing fixes.

Maybe! Possibly go a bit further and say "How-to: Python and
Databasing", which could mention SQLite (great for something tiny),
PostgreSQL (great for concurrency / multi-user), and "Other databases
can also be used, with similar or identical APIs - check out PyPI for
a module for your favorite database engine".

I guess the above paragraph is sentencing [1] me to write the article, now...

ChrisA

[1] if you'll pardon a terrible pun