>  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.

I'm coming from a production support angle here.  I have non-hacker people asking me why I'm
 using each and every package and why they are paying for it.  They
want to know who to turn to when undocumented features appear, and where they can find fixes
.  They want to be content with the knowldge that a veteran
architect-developer can work within guidelines that a novice maintenance-developer can easil
y grasp and take over.

When I roll a product into production I want to be able to acheive the following recomendati
on (in the hopefully near future):

"Python 1.x.x base distribution includes a core DBMS api that supports plugin adapters and d
rivers for the following platforms: ... "

Perhaps I am on a different mission than the general consensus here, but presently as I roll
 an application into production (and potentially never alter it again)
I must justify and include the following support information :

Base Python (build instructions, deployment instructions)
<Northrup's middle dbms layer>  (operational specifications, diagnostic procedures, pager num
ber)
MySQLModule (where to find it, which version, build instructions, deployment instructions, s
upport?)
DCOracle (where to find it, which version, build instructions, deployment instructions, supp
ort?)
<Northrup's custom application modules>  (operational specifications, diagnostic procedures, 
pager number)

I'd like to offer into this discussion that for my own benefit and the viability of Python a
s a world-class contender in the world of high-paranoia production
systems support, db-sig should unify, freeze code on a 1.0 or 1.1 python base includion, and
 push it through.

If this means that xyz time package is unfit for base python distribution inclusion, or any 
other module, compromise; then sign off on a DB api interface so that
python can move from DB-modules to DB-drivers in the paradigm of distribution.

this sig is venerable, yet glaringly absent in base python representation next to the likes 
of generic interface/driver examples such as sgml/html/http and ui/gui
interfaces.

Although I'm new to python and db-sig, I would like to know what are the requirements for a 
db-api python baseline formalization and inclusion. I think we are
very close, and I would really like to help and lend a fresh eye.

Thanks
-jim