On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer <mike...@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. -- Vernon
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
