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

[Adam DePrince]

> Agreed. I don't really see the relationship between this PEP and what
> went before. My understanding of the previous discussion was that

I know.  Here is my start of a ViewInterface PEP.  Its a closer match,
and a bit larger.  

Updated versions can be found at http://deprince.net/ideas/pep-views.txt



PEP: XXX
Title: Views 
Version: $Revision: 1.4 $
Last-Modified: $Date: 2006/03/29 04:08:48 $
Author: <placeholder>, Adam DePrince <adam.deprince at gmail.com>
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 25-March-2006
Post-History:

Abstract:

    This PEP proposes a plurality of interfaces in the spirit of
    Java's Collection interface.  These interfaces will be
    collectively known as Views.


Motivation


    Data-stores typically have a number of accessor methods that allow
    a data-store to viewed from a perspective different than its own.
    There currently exists no collection of standard interfaces for
    data-stores to choose and implement.  The result is a plethora of
    overlapping methods and semantics with no strict commonality.  The
    concern is that the applicability of duck typing in Python would
    become increasingly restricted as the result of subtle variations
    in semantics and methods for what should be otherwise similar
    implementations.


    If we hold up the dict for special consideration, the functions
    keys, items and values represent the initial effort to provide
    this abstraction.  At the time the only logical structure to map
    to was a concrete list.  With the arrival of the iteration came
    the iter variants to these functions.  Again, neither of these
    structures are the natural view of their perspective on the
    underlying data store.

    Now with the set type formally part of Python 2.4 we are faced
    again with the urge to provide a view that represents an even more
    natural perspective.  Nobody wants to see a setkeys, setitems ... 

    Further complicating the issue is similar data structures whose
    aggregation functions are conceptually similar ... without a
    central language enforced notion of what a specific variation of a
    view should sound like, we run risk of incompatibility and
    rejection of views that should otherwise be equivalent.


    The second problem lies in the connectivity between these two.
    Again, hold our dict type up for undue scrutiny as a specific
    example of a general problem, the aggregation functions do not
    provide a synchronized view into the the underlying data
    structure; the list variants are strictly snapshots of and don't
    reflect modification.  The iter variants fail upon modification.

    The notion of a view is a natural off-shot from the same
    reason we have a separate keys, items and values method.  It is
    desirable to examine a data-structure from more than one
    perspective.  While this might seem of marginal utility for a List
    -> Collection view, consider the needs of future data-structure
    designers.  A graph could be viewed as a mapping, a set of nodes
    or collection of edges.  A database object could provide
    arbitrarily complicated views.

    By providing a standard set of view interfaces we provide future
    users a way of ensuring compatibility between their existing code
    and new data store without the worry that their goose might not
    sound enough like a duck.  If your aggregate return looks like:
    then you must implement.
    

SPECIFICATION - VIEW 
 


   All views must support the SetView interface.

   UNIQUENESS

   Data-stores whose elements are not unique among themselves must
   support the Multi-View interface.  Data-stores whose elements
   are  unique among must not implement the CollectionView interface.

   ORDERED

   Data-stores whose elements are ordered, either an assigned order as
   in a list, or an intrinsic order such as a Tree, must implement the
   OrderedView interface.  Datastores whose elements are not ordered
   need not support any interface of this category.

   MAP

   Datastores that represent a map must implement the MappingView interface.  


   The following interface names are abbreviations for the following
   permutations of the above.

   * Collection View( SetView + Multiview )
   * ListView: (SetView + MultiView + OrderedView)
   * OrderedSetView (SetView + OrderedView )
   * MapView( SetView + MappingView )
   * OrderedMapView( SetView + MappingView + OrderedView )
   * MultiMapView( SetView + MultiView + MappingView )
   * OrderedMultiMapView( SetView + CollectionView + MappingView + OrderedView )
   The following interfaces alone are functional members of the ViewsInterface:

   * SetView


SPECIFICATION - VIEW CASTING


   Views may be cast between each other so long as the new view's
   implementor list is a subset of the old.

   The casting of Mapview to a not MapView implementing view must take
   place through one of the MapView's "keys, items, values"

   The following is the full ruleset for value casts.

   MapView.keys -> SetView
   MapView.items -> SetView
   Mapview.values -> CollectionView

   MultiMapView.keys -> ColletcionView
   MultiMapView.items -> CollectionView
   MultiMapView.values -> CollectionView

   <OrderedVarient>.unordered -> <UnorderedVarient>
   <NonUniqueVarient>.unqiue  -> <UniqueVarient>


SPECIFICATION - CHANGES TO CONCRETE CLASSES

   The 3 methods iter{keys,values,items} of dict will be deprecated.
   The existing keys, values and items will adopt the semantics of the
   MapView interface.

   Example use

   >>> d = {}
   >>> print d.keys()
   <SetView Implementor>


SPECIFICATION - ABSTRACT METHODS


   Implementors of the CollectionsView would be required to offer:

   Implementors of the ListView would be required to offer.


ALSO CONSIDERED

    Mutable iterators were also considered and rejected.  Numerous
    concerns were cited:

    * Excessive housekeeping for mutable iterators in dict

    * Performance problems for mutable iterators on list

    * Limited utility to due inaccessibility of iterator on common use
      cases (for-loop)