On Friday 2012-04-13 14:25 (-0700), M.-A. Lemburg <m...@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
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
