[DB-SIG] Re: [Python-Dev] Toward Python's future article

[M.-A. Lemburg]

Guido van Rossum wrote:
> On Fri, 08 Oct 2004 10:54:34 +0200, M.-A. Lemburg <mal at egenix.com> wrote:
> 
> 
>>If you feel that a certain feature is missing, I'd suggest
>>you direct your constructive criticism to the db-sig at python.org.
> 
> 
> OK, I'll bite. I would like the spec to change to require new versions
> of db API compatible modules to fully support the built-in datetime
> type, at least when used with Python 2.4 and beyond. The spec current
> recommends use of a 3rd party date/time type, which was a good idea
> back when there was no built-in alternative, but which should
> gradually be phased out now that there is. I don't want to make this
> requirement when using Python 2.3 or before, because the datetime type
> didn't have a C API then (thanks to Anthony Tuininga for contributing
> it to 2.4!).

Agreed, we should recommend usage of the datetime objects
starting with Python 2.4.

I wouldn't want to make it a requirement, though, since the DB API
is defined in terms of API signatures, not specific objects, e.g. a
module author should have the freedom to continue to use e.g. mxDateTime,
tuples or strings or leave the choice of data type to the users.

> In the remote future, all db-API compatible modules should be required
> to support the datetime module, but I want to provide for a reasonable
> transitional period.
> 
> A general comment: as specs go, the db-API spec is leaning rather far
> towards giving different implementations freedom to do things
> differently. I know this is standard practice in the SQL world, and
> where it makes sense I support it (such as differences in support for
> threading, or variations in SQL syntax). But in other areas I think
> there are differences that make switching databases more painful than
> necessary, and I would like to push implementers gently towards more
> uniformity.
> 
> I wish I could push for a standard parameter transfer mechanism, but I
> expect that this is often constrained by the underlying native APIs
> provided by various db vendors. Yet, I wish we could reach the level
> of standardization found in JDBC.

JDBC is more like an OO-wrapper on top of the low-level API defined
by the DB API.

As I've mentioned quite a few times on this list, it is well
possible to write an abstraction layer on top of the existing
database modules that exposes a JDBC-like API or a uniform
DB-API 2.0 like interface (e.g. http://sourceforge.net/projects/pydal/)
given a set of DB-API 2.0 compatible database drivers.

Think of the DB API as a driver interface specification to make
a module compatible to such a more abstract database manager.

A specification of such a database manager interface is something
that can well be done without requiring all database modules to
implement the complete (and possibly complicated) set of features.

The whole point of the DB API spec is to make things easy for the
database module author, so anything which goes beyond the low-level
nature of this interface should be left to a separate specification.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 08 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::