[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?
jacobs at penguin.theopalgroup.com
Mon Jan 5 09:37:11 EST 2004
On Mon, 5 Jan 2004, Jon Franz wrote:
> >e) Add an interface for mapping from type_id's to type classes (i.e., the
> > reverse of the mapping provided by type objects).
> Wouldn't the system I sugested saturday be just that?
> Perhaps my message was too politcal for the actual technical sugestions to
> get noticed - or the weekend timing.
Sorry -- I've been on the road and have not had the bandwidth or time to
read everything from this weekend as carefully as I'd like.
However, what I am proposing is much more modest than yours. My proposal
doesn't restrict the contents of type_codes or mandate that all type codes
have explicit Python-object representations and type constructors. I'm fine
with type_codes being backend specific cookies, since I prefer the precision
of knowing the native type code to the readability of a DB-API "type class"
in this case.
So I'm not really against the goals of your proposal, per se. I'd just
prefer to start off simple, gain more experience with how these enhancements
play out in real code (of which I have more than enough of), and only then
contemplate adding more layers of functionality (evolution, not revolution).
Better (more precise) type objects are a logical next step, followed by
generic type mapping interface, followed by more complex things like
you and Frederico are proposing (standardized type constructors and exposed
literal escaping APIs).
How does this sound?
The OPAL Group - Enterprise Systems Architect
Voice: (440) 871-6725 x 19 E-mail: jacobs at theopalgroup.com
Fax: (440) 871-6722 WWW: http://www.theopalgroup.com/
More information about the DB-SIG