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
pgp90qcXtW5fT.pgp
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com