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

[Guido van Rossum]

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

Well, that's exactly what I'm hoping to get rid of in the future. By
prescribing the use of datetime (for results -- it may remain optional
for input values), we implicitly support a much larger set of API
signatures for those results that users can depend on. Right now, if
you want to do anything useful with a result representing a timestamp,
you have to turn it into some other date/time object first whose API
you know.

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

I dunno.The db-API is pretty OO itself, and many of the db-API
interfaces feel higher-level than corresponding things in JDBC. I just
*love* how easy it is in Python to open a database, create a cursor,
execute a SELECT and retrieve the results. JDBC requires much more
work.

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

Maybe the latter is the way to go. Although I still think it's a shame
we need it at all, given how much the db-API alrady gets right.

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

Sure, but that's putting the db implementer's convenience well ahead
of the user's convenience. At some point, those db implementers that
put the user's convenience first will gain the upper hand (as the
demise of DCOracle in favor of cx_Oracle has shown).

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