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

[Paul Moore]

On 3/29/06, Adam DePrince <adam.deprince at gmail.com> wrote:
> There is more than that.  Everybody who accesses a database has to jump
> and down to extract their fields.  Wouldn't it be nice if you could say
> to your result set from a database:
>
> >>> rs.execute( "select upc, description, price from my_table" )
> >>> data = rs.fetch().fieldby( 'price','upc')
> >>> print type( data )
> <MultiViewMapping>

Um. I use databases a lot and I wouldn't find this useful...

Reasons:
1. I nearly always do "for row in cursor" to get rows one at a time
via the cursor-as-iterator interface. So I have a tuple in row, and
don't access the cursor directly for much else (and again, considering
the cursor as the "original object", I have it present so why bother
with views?)

2. Why fetch columns I'm not going to use? And even if I did, row
indexing is fine. If I want named access, I use a more complex idiom:

   cols = [d[1] for d in cursor.description]
   for row in cursor:
      row_d = dict(zip(cols, row))
      # now use row_d['column_name']

which is fine for general DB API interfaces. And many DB interfaces
have named access to rowsets as an extension, if I really care.

3. To change this would require changes to the DB API, which is
outside the scope of the Python 3000 project (apart from anything
else, it could be done now, or independently of any particular Python
release).

> Or a tree implementation of a dictionary.
>
> >>> type( tree_dict.keys() )
> <OrderedSet>

This doesn't explain why this is better than just an iterator (which
happens to return keys in sorted sequence).

> The idea that is there is so much more we can do if we had some
> mechanism of identifying at a higher level the semantics of the data
> structure.

No problem with this. But why do we NEED the extra. Nobody's disputing
that we can do more, we're just looking for a reason why more is
better. What can't we do with what we have?

(Again note - I like the idea of views, I just don't want them to be a
solution looking for a problem. If there's a problem, views can be a
solution to it, if there isn't a problem, we don't need views).

> Consider for instance if you had to dictionaries, both of which are so
> large you don't want to work on copies of their keys.   You want to know
> which items are in only the first ...
>
> dicta.keys() - dictb.keys()

[...]

> Views do partly solve the iter mutability problem by allowing many
> operations of an iteration that would otherwise take place within.
> Consider this:
>
> unwanted_words = set( ...
>
> index = { ....
>
> for k in index.keys():
>         if k in unwanted_words:
>                 del( index[ k ] )
>
> But with a view, we could say:
>
> index.keys() -= unwanted_words

Those are reasonable use cases, but artificial. Is there real life
code that would benefit? The proposed solution is a lot of machinery -
it should have correspondingly substantial benefits.

Paul.