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