[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