[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?

[Vernon Cole]

Thank you, Mark, for suggesting that we define a method for defining type
mappings!
(You saved me from having to flame you for sounding proprietary about
mxDateTime.)

Let me for a moment climb up on my soap box and say something about
standards:
(Lecture mode ON)
    It has been said that: "Standards are wonderful things, and the best
thing about them is that there are so many to choose from!"
    Let us consider for a moment a standard which failed because the
standard makers lacked the courage to make a stand. I refer to RS-422.
RS-422 was defined to extend and improve the old RS-232 serial
communications interface that we all know and use. The technical
improvements of RS-422 over RS-232 are obvious and remarkable. RS-422 is
capable of much of the same functionality as USB, and would very likely have
become as popular except for one small item. The standards body failed to
specify a physical connector for the interface. The electrical interface was
defined, but no one knew what shape of plug to attach it to. They could have
used a DB-9 or DB-7 connector, or RJ-12 or RJ-45 modular, or invented
something new. It would have made little difference. But they did not
specify, and manufacturers stayed away in droves. 
     A standard which fails to actually standardize is a leaky lifeboat.
(Lecture mode OFF)

     The dbAPI spec is in danger from this tendency to under-standardize.
I quote:
    * The preferred object types for the date/time objects are those
      defined in the mxDateTime package. It provides all necessary
      constructors and methods both at Python and C level.
    ...
    * Starting with Python 2.3, module authors can also use the object
      types defined in the standard datetime module for date/time
      processing. However, it should be noted that this does not
      expose a C API like mxDateTime does which means that integration
      with C based database modules is more difficult.

     I don't much care whether the updated standard is called 2.1 or 3.0,
the point is that the standard is incomplete and needs continued work.
Operations which should be simple are not defined.
 Date encoding and Fixed-point ASCIIdecimal fields have both been mentioned
in this thread. Named reference to a column is also missing. I fear I
released a hornet's nest of comments on that subject in September. 
    At that time, Jon Franz remarked: " Unfortunately, I think you've fallen
victim to some of the hubris present in the SIG. Many of the people here
seem perfectly fine with the status quo.  Perhaps they worked on DB-API
specifications, and thus feel protective of it?
  ...
I think perhaps it has more to do with the attitudes of those involved in
the SIG, to be honest.  I've watched this list for quite a while, and
although helpful, many people seem to shun the idea of providing higher
level interfaces in the DB-API, such as access-by-column-name."

Let's get busy on that next spec and make a good thing great.
----------
Vernon Cole
.................
-----Original Message-----
From: M.-A. Lemburg [mailto:mal at egenix.com]
Sent: Wednesday, December 31, 2003 6:31 AM
To: db-sig at python.org
Subject: Re: [DB-SIG] WHat's the status of DB modules and datetime.py
support?


David Rushby wrote:
> --- Guido van Rossum wrote:
> 
>>>--- David Rushby wrote:
>>>Most of them (AFAIK) use mx.DateTime, which is recommended by the DB
>>>API standard as follows: "The preferred object types for the
> 
> date/time
> 
>>>objects are those defined in the mxDateTime package."
>>
>>That was written years before the 2.3 datetime type existed though.
>>I expect that if the standard were written today, for use with Python
>>2.3 or later, support of the standard datetime type would be required,
>>in addition to allowing optional support for a user-specified type
>>(the callback sketched earlier in this thread seems a fine
>>mechanism).
> 
> That sounds reasonable to me, but the DB API Spec 2 is *not* being
> written today; if Spec 2.1 suddenly mandates that dates and times be
> represented via the datetime module, thousands of client apps will be
> compatible with Spec 2.0 but not Spec 2.1.  A change of this magnitude
> seems more appropriate for Spec 3.0, just as you're holding off on
> backward-incompatible changes to Python until 3.0.

I don't think we need to break anything just to allow
datetime types being used in database modules. In fact,
the current DB API revision already allows their usage
(just as it allows strings to be used for date/time
representation or tuples of values).

> A scheme such as kinterbasdb 3.1's, in which the previous
> module-specific date/time representation remains the default
> (preserving backward-compatibility), but seamless stdlib datetime
> integration is available, seems more appropriate for a Spec 2.x point
> revision.

Since Python's type system is becoming more and more flexible,
and many database modules already provide one way or another
to set type mappings, perhaps we ought to start thinking
of a new standard mechanism to setup and define these
type mappings ?!

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 31 2003)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

_______________________________________________
DB-SIG maillist  -  DB-SIG at python.org
http://mail.python.org/mailman/listinfo/db-sig