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

M.-A. Lemburg mal at egenix.com
Mon Oct 11 18:41:47 CEST 2004


Guido van Rossum wrote:
>>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. 

Fixing mappings of database data types to Python data types would
be a step backwards rather than forward in terms of user
friendliness and ability of the database module authors to provide
the users with the most suitable Python type or interface for
the data types supported by the database backends.

The DB API specification has always left the mapping open and
did so on purpose, because databases tend to invent new data types
with each new release. Most database types do not have obvious
mappings to Python types, which is why the choice of supported
types is left to the database module author.

Ideal would be to have the user configure the database modules
to return certain types depending on the database column type.
Some interfaces already provide methods to allow for this
kind of configuration.

It would be great if we could find a standardized way to
make these adjustments. The DB API would then provide
a suggested list of Python types which should be made available
by the database interface for the most common database data
types.

Users could then tell the database module what to return on
output to both avoid extensive post-processing and accomodate
for user preferences.

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

I'm not sure I follow you here: the database modules usually do
document which object types they use on output and recognize on
input.

As for date/time values: the vast majority of modules use or
can be configured to use mxDateTime objects to return date/time
values from the database, so for this particular data type there
are few surprises.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 11 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 ! ::::


More information about the DB-SIG mailing list