[DB-SIG] need some database API design advice
Chris Clark
Chris.Clark at actian.com
Fri Apr 13 23:32:05 CEST 2012
On Friday 2012-04-13 14:25 (-0700), M.-A. Lemburg <mal at egenix.com> wrote:
> Peter Eisentraut wrote:
>>> I'm not sure I like making an explicit
>>> function call for the colnames. I.e. I think sticking with the pep249
>>> description attribute is a better solution, the API already exist so
>>> clone that (when possible) in your new api.
> I agree with Chris Clark here... doing so saves you complexity in the
> dbapi layer you intend to write on top of the low level API.
>
>> That would require populating this structure on every call, which would
>> be expensive for such a low-level API, or turning the attribute into a
>> fake function, which would be evil. I think this is best left to the
>> plpydbapi layer on top of it.
> Using properties you can do this on the fly and only when
> needed. If you're writing the API in C, you can also create the
> .description tuple on demand and only when needed. You can also
> cache it in case you don't want to take the small extra hit
> of having to recreate it every time.
>
That was what I had in mind.
This is slightly off topic for C but it illustrates why an "if true" is
usually considered more Pythonic than an explicit "is [not] None" check
(for attributes/objects at any rate, not function call results).
Consider:
class MyClass():
def __nonzero__(self):
return False
x = MyClass()
if x:
print 'x is true'
else:
print 'x is False'
the "if x" check is usually a inexpensive check. For more python magic
methods, check out the excellent article
http://www.rafekettler.com/magicmethods.html
I think I confused the issue by leaving the function call in the example
when my comment suggested not doing that.
Chris
More information about the DB-SIG
mailing list