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
