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 cur
ve slim and to the point.
>  > >
>  > > mxTime's presence should be escalated to the python kernel concerns (we want better ti
me), 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/  :
           ---------------------------------------------------------