Mailman 3 SQLite module for Python 2.5 - Python-Dev

20 Oct 2004

      Hi python-dev-elopers,

Last December, we had a short thread discussing the integration of
PySQLite into Python 2.4. At the time, I was against inclusion,
because I thought PySQLite was not ripe for it, mostly because I
thought the API was not stable.

Now, I have started writing a new PySQLite module, which has the
following key features:

- Uses iterator-style SQLite 3.x API: sqlite3_compile, sqlite3_step()
  etc. This way, it is possible to use prepared statements, and for
  large resultsets, it requires less memory, because the whole
  resultset isn't fetched into memory at once any longer.

- Completely incompatible with the SQLite 0.x/1.x API: I'm free to
  create a much better API now.

- "In the face of ambiguity, refuse the temptation to guess." -
  PySQLite 1.x tries to "guess" which Python type to convert to. It's
  pretty good at it, because it queries the column type information.
  This works for, I'd say 90 % of all cases at least. But as soon as
  you use anything fancy like functions, aggregates or expressions in
  SQL, the _typeless_ nature of SQLite breaks through and it will tell
  us nothing about the declared column type (of course, because the
  data is not coming from a database column).

  So I decided to change the default behaviour and make PySQLite
  typeless by default, too. Everything will be returned as a Unicode
  string (the default might be user-configurable per connection).

  Unless, unless of course the user explicitly activates the
  "guess-mode" ;-) But to do so, she must read the docs then she will
  be aware of the fact that it only works in 90 % of all cases.

So why am I bothering you about this?

I think that a simple embedded relational database would be a good
thing to have in Python by default. And as Python 2.5 won't happen
anytime soon, there's plenty of time for developing it, getting it
stable, and integrating it.

Especially those of you that have used PySQLite in the past, do you
have any suggestions that would make the rewrite a better candidate
for inclusion into Python?

One problem I see is that even the new PySQLite will grow and try to
wrap much of the SQLite API that are not directly related to the
DB-API. If such a thing is too complicated/big for the standard
library, then maybe it would be better to produce a much simpler
PySQLite, especially for the Python standard library that leaves all
the fancy stuff out. My codename would be "embsql".

So, what would you like to see? "import sqlite", "import embsql", or
"pypi.install('pysqlite')" ?

-- Gerhard

SQLite module for Python 2.5

Gerhard Haering

tags

participants (21)