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

[Guido van Rossum]

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!).

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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)