On 3/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 3/26/06, Adam DePrince <[EMAIL PROTECTED]> wrote: > > I have a draft PEP and an implementation of mutable iterators for lists > > and dicts that supports delete only. > > > > The PEP (Mutable Iterations) and sample code can be found at: > > > > http://www.deprince.net/ideas/peps.html > > I think the PEP really needs a much stronger motivation section, > particularly with real-world examples of code that gets improved by > the additional methods. The whole discussion was spawned by a request > for determining the length of an iterable, a problem which this PEP > doesn't solve at all. What problem is this PEP solving? Is there > real-world code where this PEP would help out?
Agreed. I don't really see the relationship between this PEP and what went before. My understanding of the previous discussion was that there were a few use cases, based around the need to have more information about the underlying collection than is provided by the minimalist iterator spec, without passing concrete collections about. Guido referred to Java's collection framework, as a good example of how he saw such a facility developing. The next step was the suggestion that a PEP be written. So, in my mind, I was expecting a PEP which defined one or more new formal interfaces, (views) much like the iterator interface but with a wider set of methods. The view would be backed by a concrete collection, and the effects of view methods on on the underlying collection would be specified (e.g., view.delete() removes the entry from the view, and from the underlying collection, without affecting the element which will be produced by the next application of next(); or view.length() returns the number of elements in the underlying collection). The PEP would then go on to specify implementations to be provided in the core - views available from dict, list and set objects. That's a lot of work, and possibly more than one PEP, but that's what I imagined. The current PEP doesn't seem to match that. Some specific points: - Given that most uses of d.keys/values/items are in a for loop, there's no direct access to the iterator anyway. So the delete method is also inaccessible. This change would require code reorganisation, encouraging far more explicit passing round of iterators when looping. I'm not sure that's a good thing. - I don't see an *optional* addition to the iterator protocol as a good thing. Functions can't assume it exists for general iterators. So they have to be specified as taking iterators with a delete method". Better to give the interface a proper name and be done with it. - As Steven points out, deletion during an iteration isn't a particularly common use case. There are others (knowing the length of a sequence, or lookahead, for example) which are equally compelling. Do we get a special-purpose PEP for every one, with each concrete type growing a variety of optional iterator extensions? Python 2.x has already rejected an optional extension to some iterators allowing them to signal their length, as ultimately unhelpful. Better to have a well-defined concept which is a superset of the iterator protocol (mutable set view, say) which encapsulates a particular interface (iterator, plus other methods including length and delete) and just say that d.keys() returns a mutable set view. I won't go on any more - you probably get the idea... Paul. _______________________________________________ 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
