> 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 <[EMAIL PROTECTED]> 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) _______________________________________________ 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
