[DB-SIG] Re: WHat's the status of DB modules and datetime.py supp
jfranz at neurokode.com
Sat Jan 3 04:11:31 EST 2004
(Since I was quoted, I might as well jump in)
my two cents on the current debates:
- moving towards/requiring the new datetime objects in a future version of
the db-api sounds very good to me.
Its standard python
- Roundtrip objects just make sense.
Perhaps the names and interfaces of the type-classes should be defined, and
not the implementation. Module writers can then choose to make such objects
via c, or python, or a mixture - whichever they are more comfortable with.
As long as it walks like a BLOB and talks like a BLOB, who cares how it is
implemented internally? This is a basic pythonism, yes? This even ties into
a conversation from last month where the type_code defined within the
.description of a cursor can vary wildly between modules - see
Perhaps, instead, due to speed issues, memory issues, and implementation
issues of keeping the results in a python-object form, the types defined as
allowable for such a field (type_code) should (at the least):
a) Be defined within the standard
b) be represented within the field by a reference to a class within the
module that is a 'wrapper' for that type. This type-class should provide a
standard interface (varying based upon the underlying type), limited of
course by the precision of the underlying DB. The interfaces should be
defined within the standard.
- These classes should allow for instance creation from an output column
of that type.
- These type classes should be the same as the types used for insertion,
or at least provide interfaces so that they _work_ for insertion and hide
the details from the user.
If actual results are _not_ going to be returned as objects suitable for
insertion (memory concerns, overhead concerns, ease of use of values via
native python types), then the above would at least allow for easy
conversion of a value into insertable form without the type of the column
needing to be explicitly known, as such:
type_code = 1 # see pep 249
curs.execute("INSERT into test VALUES (%s)", (module.DateFromTicks(x),))
curs.execute("SELECT datefiled from test")
d = curs.fetchone()
curs.execute("INSERT into test VALUES(%s)", (curs.description(d),))
Of course, that's rather hard to read, so perhaps a utility function to
utilize said .description field should be made, thus we get:
curs.execute("INSERT into test VALUES(%s)", (curs.convertforinput(, d),))
The name of the function could be better.
- differences in modules currently suck.
It goes beyond just how to connect and the SQL dialects. It may be that
some of these differences are easy to smooth out and remove; if so, then why
not? Also, optional extensions are useless (IMHO) - Users fear to use them
because they might not be there if they switch modules. Either it should be
in, or it shouldn't be. Implementations of standards can have bugs - the
optional extensions muddy the water even before such bugs are found.
"Not a new version.... a new revision will do nicely. We don't
need revolution, just evolution."
To be quite literal with the terms being used: Every once in while
evolution makes giant leaps forward (anaerobic to aerobic, single-cell to
multicellular) - these leaps are revolutionary, but they are part of the
I'm not advocating ripping things down and starting from scratch - I don't
think anyone is - but I think the movement forward many people want (or at
least I want) goes beyond simple revisions such as datetime versus
mxDateTime; I think the basic module-developer versus user balance needs to
be addressed. I tend to agree with the Python-way - as Guido stated:
"making the life of the developers harder is usually considered okay if it
makes the life of the users easier"
I don't think we should make life too hard for them, however! A
middle-ground must be found. I think we'll see a short term 2.1 as a
stopgap, and a 3.0 with more drastic changes - but I could be very wrong.
NeuroKode Labs, LLC
More information about the DB-SIG