Paul Rubin wrote: > "Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> writes: >> The eventual consensus was that keys(), etc should return views on >> the dictionary. These views would be re-iterable and will have >> basically the same behaviour as the lists returned from keys(), etc. >> However, such a view could have O(1) __contains__ behaviour, and >> would not incur the overhead of creating a list and populating it - >> they would be backed by the dictionary. Of course, this introduces >> the issue of concurrent modification, but you can always get an >> independent copy by calling list(dict.keys()). > > Wait a sec, you're saying > > k0 = d.keys() > d['whee'] = 'parrot' # this can change k0??? > > That sounds broken.
That's the problem with views. You either take a snapshot of the current state, or you deal with the backing store changing. Java's solution is to raise a ConcurrentModificationException when it determines this has happened (with lots of weasel words about no guarantees). If you want an independent data set, you have to take a snapshot. For the above, that's doing: k0 = list(d.keys()) or k0 = set(d.keys()) depending on what behaviour you want. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list