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

[Stefan Rank]

on 29.03.2006 09:11 Brett Cannon said the following:
> On 3/28/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Adam DePrince wrote:
>>
[snip ... massive over-design.]
>>
>> Python is NOT Java!
>>
> 
> What I was taking away from this whole view discussion was basically
> just coming up with a simple, minimal, set/container interface that
> allows one to know about what a data structure contains.  So I
> basically expected that it would implement __contains__, __len__, and
> if people wanted delete(obj) (optional or not).  Basically a simple
> set interface where we could have a __container__/__view__/__set__
> whatever method to call to get a view of the data structure. 
> Basically a read-only (with a possible delete possibility) mapping
> interface.
> 
> I am with Greg with wanting to minimize any official protocols we
> have.  Iterators were desirable because they formalized how 'for'
> loops worked.   The reason the view topic came up was people wanted to
> be able to know if an iterator had any value to return without having
> to call next().  So the proposed interface has a use, it doesn't
> directly tie into why we added iterators as much.  Perhaps if people
> need to know if a specific iterator has a certain amount their
> iterator can also implement __len__, but it obviously would not be
> part of the iterator interface.
> 
> Without a direct reason in terms of the language needing a
> standardization of an interface, perhaps we just don't need views.  If
> people want their iterator to have a __len__ method, then fine, they
> can add it without breaking anything, just realize it isn't part of
> the iterator protocol and thus may limit what objects a function can
> accept, but that is there choice.

I think that two ideas get mixed up here:

- deletion of collection members via iterators

   this has nearly nothing to do with 'views' of collections.
   deletion via the iterator in Java is as syntactically awkward as it
   would be in Python,
   it does not allow the (new) ``for (item : collection) {}`` syntax.
   Maybe it is not worth it for Python.
   I think it would be enough to think of guarantees for iterating in the
   face of concurrent modifications: dont choke if something is deleted
   that you already iterated over and dont care if something is deleted
   that you would have iterated over later (or guarantee to fail fast?).
   so deletion would still be possible only if you have access to the
   *iterable*.

- views versus copies of collections

   views in Java just use the same interface that the original collection
   has, there are no iterators involved, and no new interfaces/types.
   examples
   (from the Java **1.5.0** docs at 
http://java.sun.com/j2se/1.5.0/docs/api/java/util/package-summary.html):

     - List.subList returns a List
       SortedSet.{headSet,subSet,tailSet} return SortedSet-s

       (and that's it!! The basic Collection does not know anything
       about relations between elements, it is a multiset,
       so it could only return the whole as a view...
       and that would be itself.)

     - Java's Map is not a Collection, but it returns views that use
       collection interfaces for:
       Map.entrySet returns a Set
       Map.keySet returns a Set
       Map.values returns a Collection (a multiset)

     - SortedMap.{headMap,subMap,tailMap} return SortedMap-s

   the {head,sub,tail}xxx things correspond to (a weak form of) slicing,
   the map methods correspond to the dict methods.
   the only difference is, they do not return a copy but internally stay
   connected to their ancestor.

   So I don't think new types/interfaces are necessary at all.
   I don't see why views should restrict the interface of the original
   iterable.
   Maybe an optional addition to all iterables to query if they have
   their own data or use data from an ancestor. Maybe a property:
   iterable.ancestor / __ancestor__ (defaults to None).

   A big question is: Should slicing also return views? and why not?

   Another one (and here's the only relation to the deletion thing):
   which guarantees in the face of modification?

   NumPy might be a good inspiration.
   (as mentioned earlier in the thread)

cheers,
stefan