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

[Adam DePrince]

On Fri, 2006-03-24 at 13:15 +1100, Delaney, Timothy (Tim) wrote:
> Jeremy Hylton wrote:
> 
> > On 3/23/06, Ian Bicking <ianb at colorstudy.com> wrote:
> >> One idea I had after reading a post of Brett's was a dual-use
> >> attribute; if you do d.keys you get an iterable (not an iterator, of
> >> course), and if you call that iterable you get a list.  This is
> >> backward compatible, arguably prettier anyway to make it a property
> >> (since there's no side effects and getting an iterable isn't
> >> expensive, the method call seems somewhat superfluous).
> > 
> > I don't think we should overload attributes name such that they are
> > sometimes attributes and sometimes methods, particularly when they
> > return things that behave almost-but-not-quite the same.  It will
> > create confusion and subtle bugs.
> 
> This whole discussion suggests to me that what would be best is if we
> defined an actual "view" protocol, and various builtins return views,
> rather than either copies or iterators.
> 
> A view provides the same access methods, etc as the object it is backed
> by. The aim of a view is to be lightweight. A view should not allow
> modification of the underlying object, but the view itself may change if
> the underlying object changes (and how it changes would need to be
> documented).
> 
> For the case of dict.keys(), a list-view would be returned. From all
> appearances, this would be an immutable sequence i.e. it would implement
> __getitem__, __iter__ and __len__.

By immutable you mean changes only arise from changes in the view's
underlying data source, correct?  The contents of the list would change
as the key-set changed.

There is one problem that I see.  A list-view actually requires more
information than the dict keys provide.  Keys in a dict are unordered,
when dict.keys() is called a synthetic ordering is created to
accommodate the fact that a list is ordered, and therefore the list must
have some order.  Right now this a reflection of a combination of hash
value and insertion order - completely arbitrary from the application's
perspective.  

When items are removed from the dict, do we leave a hole in the list?
Or do we rearrange the positions of the remaining items in the list?
Now, even if we do this in a documented fashion, if we are giving the
user the ability to index into our keys like a real list, what happens
when their saved index value no longer matches the location they
intended.  

An additional problem arises if we have multiple list-views in
existence, created at different times.  Does the existence of old list
views affect the ordering of our new views?  If not, then an older view
that has been subject to a number of insertions and deletions will have
a distinctly different ordering than a brand new view.  But if so, then
we have considerable housekeeping expenses of maintaining this
information.  

Forgive my tangent, but my only concern is that if we are going to
introduce a notion of a view, then we should be very careful about
situations where the target perspective encodes more information than
the source.  Anytime the target perspective requires more information,
such as going from an unordered to ordered or perhaps a partially
ordered to fully ordered collection, we start to entail housekeeping
associated with tracking the added information, thus ensuring the self
consistency of separate implementations of our views.  

And beyond the logistical complexity is the processing time ... dicts
are fast, anything fully ordered automatically involves O(lg(n))
insertion/deletion times.  

I like the idea of information neutral or reducing views; but for
anything that requires the addition of "synthetic information" to
construct a view worries me.

Cheers, Adam DePrince



> 
> Tim Delaney
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/adam.deprince%40gmail.com