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

Brett Cannon brett at python.org
Wed Mar 29 21:08:27 CEST 2006


On 3/29/06, Adam DePrince <adam.deprince at gmail.com> wrote:
>
> > set interface where we could have a __container__/__view__/__set__
>
> Why would I call a method to get a view on an object when the object can
> just as well implement the view?  The *only* time we want to call a
> method to get a view is when there is not one, single, completing
> definition of the object's canonical perspective should be.
>

That's my point.  What are we gaining by trying to augment iterators
or come up with some specified way to know if something contains
something else when we can get it off of the object itself.  Although,
as Nick pointed out, dicts have multiple views of their data.

But if you just want to know if a key or value exists, then you can
either use a dict's __contains__ for keys or create a set to use for
values.  That's what a view will end up having to do anyway underneath
the covers, so I don't know if we are going to get much benefit from
going through this beyond just saying dict.value_view() returns a set
of the values in a dict.  Don't know if we really need to go through
all of this formality.

> List has a single obvious view.  If you really want to see a list as a
> setview, just pretend it doesn't implement OrderedView and
> CollectionView.  Down-casting by neglect works fine.
>
> Dict doesn't, there are 4 possiable views.  The mapping view provided
> directly by the dict, and keys/values/items.

Four?  In terms of "atomic" data views, there are keys and values. 
Items could be counted, but that is just a way to pair the different
types of data in a dict together so I don't know if I would count it
as a view, let alone whether it would be useful outside of an
iterator.  But counting the dict itself is just counting the key view
twice since you can get all of that data directly from the dict
without needing a view as you pointed out above.

-Brett


More information about the Python-3000 mailing list