On Mon, Dec 04, 2006 at 07:15:35PM +0100, "Martin v. L??wis" wrote:
Brian Harring schrieb:
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).
I think this is incorrect. The implementation could well support it, putting a dummy object into the deleted key (which deletion needs to do, anyway).
The implementation already uses a sentinel (NULL)- point was that it does not support iteration over a dict that's being deleted from *currently* though. One thing to note; delitem is the easy case. Allowing for mutating the mapping as you're iterating via delitem implies that setitem should work also; setitem however can trigger a resize. Finally, if dicts were ever modified to shrink based on load, the resize there would be an issue. Mind you I've not seen proposals of that sort, just pointing out the potential.
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.
I don't think either is necessary; deletion could occur "directly".
Set's suffer the same thing; can't change what it contains while iterating, have to restart the iteration after a removal/addition.
Again, I think that's incorrect.
Again, was refering to existing implementation (and long standing rules/conventions regarding it). Set suffers the same issue with setitem meanwhile. In my opinion, no point in doing the deltitem modification without a matching setitem. Not saying I think the modification is worth it mind you, just that there should be symmetry ;) ~harring