On Wed, 2006-03-29 at 14:53 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
>
> > 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 )
>
> Nooooo....
>
> This is massive over-design.
>
> Python is NOT Java!
I couldn't agree more. My goal is *not* to introduce a weighty set of
abstractions into the Python interpreter.
I should worded this better. What I'm proposing is multiple
inheritance, mix-in classes to a basic SetView so that we can
accommodate all of the permutations of views we are likely to
encounter.
What I am *not* proposing is that we copy the Java specification into
Python. What I am proposing is that when we decide exactly which
methods will be required for each flavor of view.
This is almost more about mental bookkeeping than it is about the Python
implementation. From an implementation standpoint, how heavy will it
be? Well, maybe:
SetView implements:
.__contains__
.add
.discard
.__len__
A MultiView mixin might might add
.howmany
An OrderedView mixin might add
.__getitem__
.__setitem__
A Mapping mixin might add
.get
.set
The idea here is really to document "what it means to" offer a
particular view. The only thing heavy about it is the multiple
inheritance.
Lets not confuse heavy abstraction surrounding the motivation for a
heavy end product. IMHO P3K is a good time to sit back and ask
ourselves what we mean as opposed to what we do. Part of what I'm
calling for here in this PEP is to see .values for what it really is, a
collection. Noting here stops or makes it difficult to continue to
say:
for i in dict.items():
process( i )
But because the identity of .items as a collection remains at the fore
front of our mind, we are less likely to hobble ourselves as we did
before with the iter variants of keys/values/items.
I'm all for use cases, but keep in mind that python use cases are
motivated by the capabilities of older version of python, so they will
naturally be biased towards older ways of working.
By allowing dict.keys() to announce "I'm a SetView" we open up all sorts
of possibilities, such as direct interaction with our set type.
>>> a = set( "abcdef" )
set(['a', 'c', 'b', 'e', 'd', 'f'])
>>> d = dict( a=1 )
>>> a-d.keys()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for -: 'set' and 'list'
Consider that having d.keys be able to assert that 'I'm a set.view'
would allow the above to work with any object that understood the view.
I don't expect the set type to have special case code for lists and
iters, but it is reasonable that a set object would be able to
accommodate a set view, and the above would work.
You don't see it as a common use case right now because the proper way
of saying it today isn't particularly efficient, there is no way to say
it without either making a full copy of the keys
>>> a-set( d.iterkeys() )
set(['c', 'b', 'e', 'd', 'f'])
>>>
or building a loop. Ergo, the for-loop becomes the common use case.
Besides, common use cases are too often about what benchmarks the
fastest anyway :-)
My allowing for a closer conceptual match, and more abstract types, we
increase the number of opportunities for duck typing to "just work."
If we had a SetView interface, everybody that implemented that interface
would "just work" in the above example.
Cheers - Adam DePrince
_______________________________________________
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
