[PYTHON DB-SIG] DB-Modules returning lists of dicts

Harri Pasanen pa@tekla.fi
Thu, 9 Jan 1997 17:42:05 +0200

David Walton writes:
> Hey folks,
> May I assume that due to the lack of response (with the exception
> of Glenn Colby's, thanks for your comments Glenn), that there is
> no interest out there in Python database modules giving the *option*
> to return a list of dictionaries as an alternative to the list
> of tuples that are currently returned?
> Glenn, comments that at the Jackson Laboratory, while they are
> still having their Sybase module return lists of dictionaries, they
> are doing a rewrite that will cause it to return a list of tuples
> instead (like the API).  Glenn also comments that he is setting up
> a SQL class that abstracts away the programmers knowledge of
> the schema, and that he can't see any use for returning a list
> of dictionaries due to the cost in the over-head of the datastructure.
> (part of what I just said may have come from mail that Glenn and
> I exchanged after his initial message.  Glenn, please correct me
> if I misinterpreted your words.)
> This is fine for their needs.  In our case however, we have no desire 
> to abstract away the relational schema from our developers.  We also
> find it very useful to be able to reference the results of a query
> by column name, instead of column number.  It makes it possible for
> any code that is using a 'SELECT * FROM foo' to continue to function
> when a column is inserted to the schema for foo.  And let me say, 
> at this point in time this happens frequently to us, because our
> schema is still a moving target.
> I realize that it is possible to take the "description" provided
> by the API and associate the column names with the columns in my
> list of tuples.  I do that now.  I just thought it would be
> a little more efficient to have the module returning the rows to me
> as dictionaries in the first place.
> I'm very interested in knowing why folks find this option undesirable.
> (if they actually do)
> Glenn's reason being "there is so much space overhead when returning 
> a dictionary for each row in the database.".  However, for us this
> is not a concern (at least right now), and we would find the
> option useful.
> Thanks again for any input folks can contribute.

I think the space overhead criteria alone is sufficiently strong to do
without a dictionary for each row.

The proper approach in my mind is to wrap the tuple access inside a
class, which can provide very natural access to each field.

Possible interfaces to data, assuming row below is an instance of
above mention wrapper class.

row.field1     # access field1 using __getattr__, name of field is 'field1'
row._tuple[0]  # access field1 directly via tuple
row.GetAttribute("field1")  # access via class internal dict.

If I remember, Jim Fulton proposed something like this long time ago,
and I've personally implemented this kind of an interface.  Works very
nicely.  Jim's proposal was more detailed than this quick sketch.
I suggest you browse past archives for this sig, if those are

Harri Pasanen

DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org