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

[Georg Brandl]

Adam DePrince wrote:
>> Maybe. I need a volunteer to write the PEP!
> 
> PEP: XXX
> Title: Mutable Iterations

Comments (mostly grammar) inline.

>     This PEP proposes an extension to the iteration protocol to
>     support deletion.  Invocation of the delete method would result in
                      ^ "of items of the objected iterated over"?

>     the deletion of the corresponding object from the iterations
>     underlying data store.
> 
>     This PEP further proposes that dict.iter{keys,items,values} be
>     removed and the functions dict.{keys,items,values} return iters of
>     this new deletable variation, and that the iter prefixed function
               ^^^^^^^^^ the iterator is deletable?
>     variations be deprecated.
                    ^^^^^^^^^^ deprecated or removed, like written above?
> 
>     Support for delete would become an optional component of the iter
                  ^^^^^^ "deletion"?
>     protocol.
> 
> Motivation
> 
>     The current dictionary API has separate functions to return lists
>     or iters for each of keys, values and items.  This is cumbersome
>     and annoying, yet is tolerated because neither alone possesses the
>     full functionality desired by the python community.
> 
>     The iter variation provides all of the performance advantages
>     normally associated with iters; primarily minimal in-flight memory
>     consumption.  Its use, however, denies the user the ability to
>     mutate the underlying data structure.  Modification of the
>     underlying dict results in in a RuntimeError upon the subsequent
>     call of iter.next
                       ^"()."
> 
>     The non-iter variation returns a snapshot of the current
>     dictionary state stored within a list.  This has the advantage of
>     permitting in-situ mutation of the underlying dictionary without
>     upsetting the current loop.  The disadvantage is that of
                            ^^^^ no mention of a loop before
>     performance and resource consumption; the portions requested of
>     the underlying dictionary could easily exceed marginal memory.
> 
>     In many situation, such as with dictionaries that consume
                       ^"s"                                    ^" a"
>     substantial portion of memory, or dictionary implementations that
>     operate out of core, the list variant of these operations is
>     effectively unavailable.
> 
>     A common programming pattern is to iterate over the elements of a
>     dictionary selecting those for removal.  Somewhat less common is
>     the insertion of elements during the traversal.  It is the former
>     that we seek to address at this time.
> 
>     This PEP attempts to merge the benefits of the list and iter
>     variants of keys/values/items under a single implementation.
> 
> SPECIFICATION:
> 
>     Example of desired operation:
> 
>     >>> d = {'foo':1,'bar':2 }
>     >>> i = d.values()
>     >>> print i.next()
>     2
>     >>> i.delete()
>     >>> print i.next()
>     1
>     >>> print d
>     {'foo':1}
>     >>> print i.next()
>     StopIteration
> 
> SPECIAL CONSIDERATION
> 
>     This would require the implementation of a non-rehashing variant
>     of dict.__del__.
              ^^^^^^^ do you mean __delitem__?

>     It may not be possible to prevent rehashing upon the insertion of
>     an element into a dict as it is for a delete, therefore element
>     insertion is not being considered at this time.
> 
> ALSO CONSIDERED
> 
>     Implementation is the style of the JAVA views proposal.  One
                     ^^ "in"
>     concrete example of a list view superimposed upon a dict.
                       ^^ "is"?
>     Concerns were expressed about the record keeping and computational
>     overhead of addressing holes that would appear within the list
>     upon insertion and deletion.

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/python-3000/attachments/20060325/7dc76c6e/attachment.pgp