[DB-SIG] annotated 1.1 spec / feedback

[M.-A. Lemburg]

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 convenience 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 the 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 flag 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 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.

> 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 contribute 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 everything *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 modules 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 my own middle-interface drivers in lack of standardized
> conventions.  I would love to help push through something simple, solid, perhaps not idealistic, 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/  :
           ---------------------------------------------------------