
On Sun, Dec 03, 2006 at 06:24:17AM -0600, Ben Wing wrote:
many times writing somewhat complex loops over lists i've found the need to sometimes delete an item from the list. currently there's no easy way to do so; basically, you have to write something like
i = 0 while i < len(list): el = list[i] ...do something... if el should be deleted: del list[i] else: i += 1
note that you can't write
for x in list:
or even
for i in xrange(len(list)):
note also that you need to do some trickiness to adjust the index appropriately when deleting.
i'd much rather see something like:
for x:iter in list: ...do something... if x should be deleted: iter.delete()
the idea is that you have a way of retrieving both the element itself and the iterator for the element, so that you can then call methods on the iterator. it shouldn't be too hard to implement iter.delete(), as well as iter.insert() and similar functions. (the recent changes to the generator protocol in 2.5 might help.)
the only question then is how to access the iterator. the syntax i've proposed, with `x:iter', seems fairly logical (note that parallels with slice notation, which also uses a colon) and doesn't introduce any new operators. (comma is impossible since `for x,iter in list:' already has a meaning)
btw someone is probably going to come out and say "why don't you just use a list comprehension with an `if' clause? the problems are [1] i'd like this to be destructive;
Just use slice assignment. l = list(xrange(100)) l2 = [x for x in l if x > 50] l[:] = l2[:]
[2] i'd like this to work over non-lists as well, e.g. hash-tables;
There in is the sucky part; iterator protocol is simple; what you're proposing is extending iterators so that they recall the last value (else iter.delete() would not do anything), which... eh. Think it sucks, to say the least ;) Simple example of where this gets ugly is in iterating over a file.
[3] list comprehensions work well in simple cases, but in more complicated cases when you may be doing various things on each step, and might not know whether you need to delete or insert an element until after you've done various other things, a list comprehension would not fit naturally;
Slice assignments work fine here.
[4] this mechanism is extendible to insertions, replacements and other such changes as well as just filterings.
Yes it is, except the new 'iterator' isn't as extendable to arbitrary sequences after. Also is ignoring the fact that doing in place deletion of lists as you walk can get massively costly quick; worst case, quad for removal (hence collections.deque existing). ~harring