I proclaimed:
>>> [...] Any row should "look like a dictionary", but python's
>>> neat OO interface means we can implement it however we like....
>... I think a cleaner model is that of records. That is,
>rather than:
> row['some_column_name']
>allow:
> row.some_column_name
>I'd say that database users think more in terms of tuples with
>attributes, than they do of dictionaries....
yes, you're right. But this makes attributes "non-first class".
Bugger the users! I'm a programmer! If I want to pass rows into a
procedure (eg, a neat tkinter form generator), I'd like to be able to
make the procedure work for rows with differing attribute sets. With
a dictionary I can simply say R.keys() or something to help here.
This would be awkward at best if the "core" representation looked like
a record.
Also, what if the row object has other methods or attributes?
R.foriegn_keys
R.primary_key
R.update( newvalues )
A dict would avoid name collisions.
(Well, if you really like those silly users you can layer a "record"
wrapper (or filter) on the core dict interpretation before you present the row
to the user).
-a.
===
Vote for me, because I know everything,
and I'm always right.
-- Firesign Theater (again), possible misquoted.