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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
