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

Jon Franz jfranz at neurokode.com
Mon Jan 12 05:24:41 EST 2004

> In my view, what you want can be accomplished by a helper routine.  So
> instead of using the code_code in the description directly as a type
> constructor, one could call a function, say,
> Or, if you really want syntactic sugar, one could define a type_code
> that includes __call__ method that "does the right thing".  Unfortunately,
> "the right thing" is frequently not so simple.

Sorry for the delay in responding - my notebook died last week and
it has taken me awhile to catch up with the backlog.

Instead of a helper routine, how about a code to type mapping?
Currently you can manually do a bunch of if-elif statements to compare
the code against the types, but a simple mapping would make things
much cleaner - less code, and easy to understand - and flexible enough
to handle new types that later revisions of the API might mandate.
Call it the TypesByCode mapping (unless someone else thinks of
something better)
It will be DB specific, but it should be very easy to implement, and
wouldn't cause any problems with the new type heirarchy being
I would think returning the most specific type possible would be useful
in some cases, meanwhile at other times returning the higher-level
type would be useful, so perhaps the values should contain a tuple
- index 0 gets the general, top level type reference, and index 1 gets
the most specific reference.  Sometimes these would be the same.

Thus, you' could do something like this:
# specific and general type of column at index 2
mycode = module.cursor.description[2][1] # pep 249
myType = module.TypesByCode[mycode][1]  # specific type
myGeneralType = module.TypesByCode[mycode][0]

This would keep native type_codes, be backwards compatible, and
yet allow for some useful functionality.  Ideas/Thoughts?

PS: another small suggestion.  I think it would be useful for the API to
define required constants for the modules to expose, namely for the
different fields in description and their indexes.  It seems trivial, and
but I imagine it would be useful for many people to avoid opening the
PEP every time they needed the index for a field in .description.
Similarly, if the TypesByCode mapping were added, I'd suggest two
new constants for the indexes of the general and specific types
within the returned tuple.

More information about the DB-SIG mailing list