[Python-3000] Iterators for dict keys, values, and items == annoying :)

[Kevin Jacobs <jacobs@bioinformed.com>]

On 3/29/06, Ian Bicking <ianb at colorstudy.com> wrote:
>
> Greg Ewing wrote:
> > On 3/29/06, Adam DePrince <adam.deprince at gmail.com> wrote:
> >
> >>>>> rs.execute( "select upc, description, price from my_table" )
> >>>>> data = rs.fetch().fieldby( '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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060330/cd0a998c/attachment.html