[DB-SIG] Controlling return types, again

[Carsten Haese]

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