[DB-SIG] annotated 1.1 spec / feedback

Greg Stein gstein@lyra.org
Tue, 16 Mar 1999 02:02:08 -0800


M.-A. Lemburg wrote:
> 
> James Northrup wrote:
> >...
> > Where we have:
> >           Date(year,month,day)
> >                This function constructs an object holding a date value.
> >
> >           Time(hour,minute,second)
> >                This function constructs an object holding a time value.
> >
> >           Timestamp(year,month,day,hour,minute,second)
> >                This function constructs an object holding a time stamp value.

Why do we need three variations? Do we actually have issues with input
binding where the discrimination matters? We never had any problems
before, when we just had a date/time object.

>...
> > Retract:
> > ***
> > mxTime as an inherent piece of db-sig discussion.
> >
> > Use mxTime as is necesary for implemenation purposes, but keep the python learning curve slim and to the point.
> >
> > mxTime's presence should be escalated to the python kernel concerns (we want better time), however, this db-sig has become tangental and worrisome with no
> > substantial core interface adherence in it's 1.0 incarnation.
> 
> I don't think we can convince Guido of adding mxDateTime to the
> Python core. Still, installing that package is not any more
> difficult than installing a typcial database interface. I don't
> see a point in omitting useful software that is readily available
> just because it does not belong to the language core.

Creating a hard dependency on mxDateTime will place us right back into
the problem that we had with "dbi". People like simplicity and they'll
cut corners. I've been using mysqldb quite a bit lately, and it doesn't
use dbi. I doubt that it would change to use mxDateTime.

People want to distribute a single .c file and be done with it. That is
definitely easier on the module implementor than using mxDateTime.

I understand that you want to see people using your module, and I
generally agree with it, but I don't think it is a good idea for us to
mandate it. The API must support a DateTime(ticks) function which can
map onto a simple dbiDate-like object. A module implementor must be able
to use a simple ticks-based object (e.g. copy the code out of the
(deprecated) dbi module).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/