pysqlite design decisions

Gerhard Häring <[email protected]>
Newsgroups gmane.comp.python.db.pysqlite.user
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glyph Lefkowitz asked a few questions in a tracker item, so I'll try to
post a few notes here, so we can have a discussion about pysqlite's design
and possible improvements:

Unfortunately, there is no rationale anywhere about why so much of pysqlite
is written in C although some information is spread in old mailing list
posts (around 08/2004 until 10/2004).

The reason was one word: performance. And yes, I know about premature
optimization and all ...

At the time, there were people who used the low-level interface of pysqlite
0.x for performance reasons and avoided the Python layer. And because of
various measurements that I performed I knew that there was significant
overhead in database adapters that consist of a C and Python layer. I also
studied the code of the psycopg PostgreSQL adapter and saw that

a) an all-C solution is really doable, it's not *that* much more difficult
to use the Python-C API than to use plain Python
b) it is a hell of a lot faster than the other adapter I am/was involved
in, pyPgSQL

A little later during pysqlite2 development, there was Roger Binns who
created his own solution APSW because he needed something now instead of
later and something that did as little behind the scenes as possible.

That reinforced my tendency to keep things simple and sane by default for
pysqlite2:

- - be as compatible with the DB-API 2 standard as possible, but *not* more,
like pysqlite 0.x tried, and failed to - there, things worked conforming to
the standard in some cases, but not in others, because of limitations of SQLite
- - at the same time, don't try to fight SQLite semantics, but try to join
the SQLite and Python type systems in a clearly defined manner (converters
and adapters)
- - don't use any addons by default, but offer them optionally (like an
improved row type instead of plain tuples for result set rows)
- - on top of the DB-API, wrap other useful SQLite API calls
- - offer additional convenience functions that could get into a possible
DB-API 3.0, like execute() shortcut methods on the connection object

I hope that explains at least partly why pysqlite looks like it looks today ...

- -- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFchQKdIO4ozGCH14RAjvEAJwNQeBPNJsuZWtb+MgUFNSmQuy7GACdGIkt
Y4nFq1YysgwJYbJPx/le1oE=
=hIvL
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.