James Northrup wrote:
>  
>  > The updated spec (1.1a8) is at:
>  >
>  >         http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html
>  >
>  > I've folded dbi into the module interface and added constructors
>  > Date, Time and Timestamp (as well as corresponding type codes).
>  > Note that only the constructor names are defined -- not whether
>  > the result from calling these specifies a certain type or instance.
>  >
>  > Hmm. Maybe it'll be 2.0 after all... punting dbi, new
>  > interfaces, different semantics...
>  >
>  
>  reading through your 1.1a8 spec I have the following remarks hoping to offer in some conve
nience functions with the python time module:
>  
>  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.
>  
>  Add:
>  TimeStamp (string[, format])
>  *** (time.strptime compatible)
>                 This function constructs an object holding a time stamp value.
>      Parse a string representing a time according to a format. The format parameter uses th
e same directives as those used by time.strptime(); it defaults to
>  "%a %b %d %H:%M:%S %Y" which matches the formatting returned by ctime().
>  
>  Add:
>  TimeStamp (tuple)
>  *** (time.mktime or time.asctime compatible)
>                 This function constructs an object holding a time stamp value.
>      Its argument is the full 9-tuple (since the dst flag is needed -- pass -1 as the dst f
lag if it is unknown) which expresses the time in local time, not
>  UTC.

Note that we'd need three different names for the above since
Python does do allow type inference.

>  Add:
>  gmtime (TimeStamp)
>  *** (time.gmtime identical return)
>      Convert a TimeStamp to a time tuple in UTC in which the dst flag is always zero.
>  
>  Add:
>  localtime (TimeStamp)
>  *** (time.localtime identical return)
>       Converts to local time. The dst flag is set to 1 when DST applies to the given time.

All of the above are easily done using the existing mxDateTime
constructors. Why should we add them to the DB API specification ?
If a module writer were not to use mxDateTime then it would only make
things more complicated for him.

>  Retract:
>  ***
>  mxTime as an inherent piece of db-sig discussion.
>  
>  Use mxTime as is necesary for implemenation purposes, but keep the python learning curve s
lim 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.

>  while DB-sig seems to have made a great case for a more reliable time library, that thread
 should be processed in a general-python-improvement sig.
>  
>  I see this SIG moving very swiftly towards an idealistic pinnacle.  I would like to contri
bute my 2 cents worth, I want a simple and direct DB interface
>  class to adhere to.  I want to be able to teach a neophyte DBA who just learned SQL everyt
hing *except* OO syntactic sugar.  I want their experience with
>  maintaining my python application to be as simple as looking up the python core api and mo
dules and adding a new function call.
> 
>  furthermore, I want to see python have the full benefit of mxTime as a default transparent
 upgrade, and would love to help make this a reality.
>  
>  I'm doing significant amounts of multi-dbms python work presently and am in fact writing m
y own middle-interface drivers in lack of standardized
>  conventions.  I would love to help push through something simple, solid, perhaps not ideal
istic, but at least published and distributed with working
>  implementation rsn.

Agreed. The API should stay simple and an OO layer should be built
on top of it in Python; still, for a few things we'll have
to resort to objects for the interface specification simply because
it is the only way of providing vital information to the module.

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