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

[Adam DePrince]

On Thu, 2006-03-30 at 21:56 -0800, Guido van Rossum wrote:
> > Adam DePrince wrote:
> > > No reason we can't make other string operations views as well ...
> > > concatenation is one example.  If I recall, that's how snobol handles
> > > strings, view upon view upon view.
> 
> But that's irrelevant for immutable strings -- views are about
> semantic links, not implementation.

I confess, I was perpetuating the abuse of the term view; snobol strings
have no bearing other than comic relief on what we are doing here.  

To treat slicing as a view does have some bearing ... but I'll get to
that in a moment.

I believe I need to break this PEP up into several parts.  The first
part needs formalize a practice that is starting to become prevalent in
Python's C implementation with the introduction of iter ... the notion
of a surrogate.   

Right now an iter can be over anything, real python or "verbal
description" ... iter-values is the later.  It is an iter that mutates
the form of the dict prior to returning it.  

I think where I want to take the view proposal, which is really a
broader form of the list/iter debate is to separate the mutation
associated with a view from an iter, which basically embodies "the
for-loop's state." 

There has been some confusion ... and just to address it, the vision
that I see is for items to be a pointer to the parasite rather than a
generator for an iter/list.  For backwards compatibility dict.items
would return self when called.  There is to be a one-to-one relationship
between an object and a view.  d is d asserts d.items is d.items under
the view proposal, and d.items is some sort of parasitic object that
hangs off of the dict for the single purpose of providing this different
perspective.  

d.items will not have a next method for the same reason d doesn't, that
isn't the place to store our loop state :-)  Instead, each will have its
own .__iter__ from which fresh objects whose sole ambition is to store a
loop pointer will spring into existence. 

There are two ways we could create views ... the fixed reference .items,
again with self on call for backwards compatibility, and a proper view
generator (for instances that require the acceptance of parameters).  

On Thu, 2006-03-30 at 12:05 +1200, Greg Ewing wrote:
> Stefan Rank wrote:
> 
> >    A big question is: Should slicing also return views? and why not?
> 
> That's been considered before, in relation to strings.
> The stumbling block is the problem of a view of a
> small part of the object keeping the whole thing
> alive and using up memory.
> 
> While having a separate way of getting slice-views
> could be useful, I think it would be too big a
> change in semantics to make it the default
> behaviour of slicing notation.

The conversation about slicing came from Stefan Rank's earlier question
(copied above)    

We could very well implement a generic OrderdView -> OrderedView mutator
that effectively performs slicing.  Its not absurd for that would become
the default means of slicing in Python, override-able when a data
structure specific version has a compelling performance advantage.  

It is my expectation that eventually number of the things we do in
python could eventual be seen as "view" mutations; operations defined
between two interfaces rather than a concrete class and an interface.  

This is getting rather ambitious ... I'm going to sit back and rework
the PEP's both address the concerns that people have had, size, and to
further clarify the relationship between data-stores, views, iters and
their cousins, returned lists.  

Cheers - Adam DePrince