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

[Brian Harring]

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
-------------- 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/dd0ead0f/attachment.pgp