[DB-SIG] WHat's the status of DB modules and datetime.py support?

[David Rushby]

--- Guido van Rossum wrote:
>> --- David Rushby wrote:
>> Most of them (AFAIK) use mx.DateTime, which is recommended by the DB
>> API standard as follows: "The preferred object types for the
date/time
>> objects are those defined in the mxDateTime package."
>
>That was written years before the 2.3 datetime type existed though.
>I expect that if the standard were written today, for use with Python
>2.3 or later, support of the standard datetime type would be required,
>in addition to allowing optional support for a user-specified type
>(the callback sketched earlier in this thread seems a fine
>mechanism).

That sounds reasonable to me, but the DB API Spec 2 is *not* being
written today; if Spec 2.1 suddenly mandates that dates and times be
represented via the datetime module, thousands of client apps will be
compatible with Spec 2.0 but not Spec 2.1.  A change of this magnitude
seems more appropriate for Spec 3.0, just as you're holding off on
backward-incompatible changes to Python until 3.0.

A scheme such as kinterbasdb 3.1's, in which the previous
module-specific date/time representation remains the default
(preserving backward-compatibility), but seamless stdlib datetime
integration is available, seems more appropriate for a Spec 2.x point
revision.

>> If the standard is updated to make a definite pronouncement on the
>> date/time representation, how about also specifying a fixed point
>> representation?  It seems logical to address both of these
ambiguities
>> at the same time.
>
>Why?  We have a working datetime type in 2.3.  We don't have a
>fixed-point type anywhere (the Decimal type in the sandbox is decimal
>*floating* point).

As I see it, a backward-incompatible change such as that which you're
suggesting should be reserved for a major revision.  While making that
revision, why not address the numerous other sore points and
inconsistencies that DB API users perennially complain about? 
Otherwise we'll be crossing bump after bump of limited-scope
backward-incompatibilities; these are more difficult for maintainers to
keep track of than infrequent but broad redefinitions.  Most major
programming platforms follow the "infrequent but broad redefinition"
model when backward incompatibilities are deemed necessary (e.g.,
Python 2->3, Perl 5->6, Zope 2->3, Apache 1->2, and Win32->.NET).

As for the specifics of the Python representation of NUMERIC/DECIMAL
database values, my concern is that there be a standard way to move the
values to and from the database precisely.  Unless I'm missing
something, the sandbox Decimal.Decimal type can accomplish this even
though it's not fixed-point.    What happens in the Python client code
when arithmetic is performed on the values is not a database I/O issue.
 Rounding values bound for storage in the database is, but a DB API
driver could perform this operation via the Decimal.Decimal.fixedPoint
method, leaving control of the specific rounding algorithm to the
client programmer (via the rounding facilities of the Decimal module).

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003