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 _______________________________________________ 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
