[DB-SIG] annotated 1.1 spec / feedback

[M.-A. Lemburg]

Greg Stein wrote:
> 
> 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.

These are the standard date/time objects defined by SQL. It seemed
natural to define these constructors at the module level too.
Date() is not capable of representing time only information.

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

Sorry. That was a misunderstanding: I don't intend to hard code
mxDateTime into the spec. The spec only defines constructor names;
the module implementor can then code these constructors in any way he
likes. mxDateTime is only meant as offering, since it already provides
all necessary functionality.

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

Agreed; though things are moving on the distutils list, so that
may soon not be such a big problem anymore.

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

I think we should get rid off Unix ticks in the specification
completely. They introduce too many errors and quirks (e.g. only
think of dates prior to 1.1.70).

If a module implementor wants to use ticks anyway, he can use
time.mktime to create the ticks integer in his module's Date()
constructor, e.g.

def Date(year,month,day):
   import time
   return time.mktime(year,month,day,0,0,0,0,0,-1)

While ticks are easy to use, many database can't handle them
in the APIs anyway, so there's really no need for them to go
explicitly into the spec.

-- 
Marc-Andre Lemburg                               Y2000: 290 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------