[Python-Dev] a feature i'd like to see in python #1: better iteration control

[Brian Harring]

On Sun, Dec 03, 2006 at 08:35:58PM -0600, Ben Wing wrote:
> but i still don't see why supporting iter.delete() is so wrong.  clearly 
> it doesn't need to work on files or other such things where it doesn't 
> make sense.
>
> before you diss this completely, note that java supports exactly the 
> same thing:
> 
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html

Not all iterators would support remove; that right there is a bit of 
an issue since right now, the only exception you need to expect for 
iterator protocol is StopIteration being thrown when the iterator has 
nothing more to yield.

So, it's no longer simpler, which is a bit of a con in my opinion.

Question is, where _would_ it work?  Doesn't really make much 
sense for generators (doable with 2.5, but most generators are just 
that, generators, not modifiable views), doesn't make sense for 
itertools.* for the most part, since it's combination of iterators.

For dict; it actually *cannot* work.  You can't remove keys from a 
dict as you're iterating over it (can change the val of a key, but not 
remove the key).  So iter.delete would require fair bit of changes 
internally to dict, either tracking what it's yielded already, or 
forcing iterkeys to actually be iter(keys()) (creating an intermediate 
list), which is worse for memory usage and general performance.

Set's suffer the same thing; can't change what it contains while 
iterating, have to restart the iteration after a removal/addition.

Tuples are immutable, so end of discusion there.

Leaves lists... which personally, I view as a mostly bad thing to be 
doing anyways.  Trying to pop an item out of the middle of a list 
results in shifting everything right of it one spot to the left; this 
sucks from a performance standpoint, again, worst case, quad.

Now... occasionally, have to do it admittedly.  But it's not something 
you actaully want to be doing in your code all that much- admittedly 
generating a new list to avoid that hit also sucks somewhat, but the 
worst case there is far more behaved, a temp trade of space vs 
runtime.

What I'm trying to get at is that what iter(list).next().delete() 
would do isn't a good thing to paper over, it makes the op look like 
it costs nothing when it can cost a _lot_.

Unless I'm missing something, the only real usage of this is a list 
(could do it on files also, although that would suffer the same 
issue as a list, just worse via truncate calls).  Would work better on 
collections.deque, but deque is a linked list and used rather 
selectively.

So... why add it, if it's basically for one major type, and it's 
not a good idea to blindly do such an action on that type in the first 
place? 

~harring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20061203/fcae3584/attachment.pgp