Thanks for your input. I won't bother quoting all that, because it seems to me that we actually have a lot of common ground.
You seem to be proposing that the user should write a converter dispatcher function that returns a "binding hint" and an adapter function. In my proposal, the dispatcher is a dictionary-like object, and it could even be a dictionary in cases where the type description can be used as a key, and the binding hint would ride along on the adapter function itself as an attribute. However, I suppose the dispatcher could just as easily return a tuple of binding hint and adapter function as in your outline. The advantage of my proposal is that it's easier to combine "canned" converters as long as those canned converters implement __add__, which I would require of the canned converters for common use cases. I listed a few common use cases in my proposal, including but not limited to whether to fetch chars as byte strings or unicode objects, whether to fetch decimals as floats or decimal objects, etc. In my opinion it is vital that the application developer be able to choose such standard mappings with code that's a) minimal and b) database independent. With the code you're proposing, I don't see how the application developer would combine canned standard converters without writing a big boilerplate if/elif/else dispatcher that contains lots of database dependent type descriptors. [P.S. My email problem has been corrected, thanks for bringing it to my attention. Apparently your mail exchanger is on the same IP range as a known spammer, and my sysadmin blocked the entire range without realizing that he was throwing out the baby with the bathwater.] Best regards, -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
