[DB-SIG] Some obscurity with paramstyle

Vernon Cole vernondcole at gmail.com
Mon Jul 18 03:10:42 CEST 2011

On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer <mike_mp at zzzcomputing.com>wrote:

> On Jul 17, 2011, at 1:52 AM, Vernon Cole wrote:
> > 2) some major applications (e.g. django) assume %s format.
> >
> > But I am +1 for the idea anyway.
> But not all DBAPIs support %s format, do you mean that Django assumes %s
> format for those DBAPIs that are known to do so ?   Shouldn't they be at
> least using .paramstyle to determine that ?
> Well, that's how the 2.0 spec assumes things should work: the DBAPI module
tells you which paramstyle it uses, then you write your program five
different ways to cover the five possibilities.  But django does not do that
(does anyone??) -- it blindly assumes that all DBAPI's use %s.  That's why
someone made a fork of adodbapi in order to support Microsoft SQL server in
django.  ADO uses qmark, so the fork version had to convert %s to qmark
before executing the SQL statements.   I pulled the format conversion code
(and some other improvements) back into the release version of adodbapi,
fixed it so that it does not break % signs in literals, and added a feature
so that a programmer can request either qmark, format, or named paramstyle.
That's why I favor the suggestion. Having written a version which does
format conversion, I know that it is not hard to do.

Is there a path to changes being made in the DBAPI?   i.e. would there be a
> DBAPI 3 ?

That possibility has been discussed before, and is particularly timely given
that it is impossible to write a PEP 249 compliant module in Python 3.  [For
example, the PEP states that an Error exception "must be a subclass of the
Python StandardError" -- which Python 3 does not support.]

Marc-André Lemburg (the author of PEP 249) came out against an update --
mostly due to performance reasons.  This is understandable, because his
company produces a very efficient db api module.  The features which have
been suggested for a possible DBAPI 3.0 would add some significant overhead
in some situations. The worry is real. Compare the mxDateTime module (also
from Mark-Andre's company) with the (newer) standard datetime module, and
you will see that datetime is a slow dog. (I use it anyway.)

On the other hand, GVR is in favor of an update. When MAL suggested that
some ease-of-use improvements (such as named columns) would make
implementation of a module more difficult, The BDFL replied that we should
make things easier for the user, not the module author. [ I am relying on my
memory -- my copy of the exchange got deleted and I am too lazy to look it
up in the archive. ;) ]

So Yes, there are a TON of new language constructs which could be addressed
in an updated API version.  The use of a cursor as an iterator is supported
by most DB API modules, but not mentioned in PEP 249.  A cursor and/or a
connection should probably be context managers, so that they will work in a
"with" statement.  There should be a better definition of how BINARY fields
work with byte() data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20110717/f9287d46/attachment.html>

More information about the DB-SIG mailing list