On 3/29/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
Greg Ewing wrote:
> On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
>
>>>>> rs.execute( "select upc, description, price from my_table" )
>>>>> data = "" 'price','upc')
>>>>> print type( data )
>> <MultiViewMapping>
>
> Seems to me it would be a better idea for the DB
> module to return tuple-with-attributes objects for
> the rows in the first place, rather than plain
> tuples.
>
> When I get around to reworking my custom Firebird
> module, I'm going to make it do that.

See the db_row module from http://opensource.theopalgroup.com/.  It attempts to provide a tuple-looking (sequence-like) object that also provides "object-like" and "mapping-like" interfaces that is both space and time efficient.  While being far from a perfect solution, it does solve many practical problems and is used by many.


Which is off-topic here, except to say that a view on the tuple would be
useful in a way that returning a fancy tuple would not, because it could
wrap any DB-API-compliant result set.  Which might still be off-topic,
since the implementation of that particular view would be mostly
unrelated to any other view we've talked about here.  Except perhaps to
note that patterns for building light and fast views would also be nice.


db_api result sets are the tip of the iceberg, though an important start.  These annotated tuples can also be used in many other bulk data processing contexts where metadata is either implicit or decoupled with the data values -- e.g., processing csv files with the csv module.


-Kevin

_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to