ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> db-sig
db-sig
Re: [DB-SIG] annotated 1.1 spec / feedback
by Greg Stein other posts by this author
Mar 16 1999 2:02AM messages near this date
Re: [DB-SIG] annotated 1.1 spec / feedback | Re: [DB-SIG] annotated 1.1 spec / feedback
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/

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved