You bring up a good point. the for x in d: notation is a relativly
new construction, for x in d.keys() is much older. Some of the value
of d.keys() goes away because we have this new construction, but
there's some reasons to keep it around:
1. Consitency. You can get the values, you can get the
Paul Rubin wrote:
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes:
If you want an independent data set, you have to take a snapshot.
For the above, that's doing:
k0 = list(d.keys())
I don't understand. Why have .keys() at all, if it doesn't get you
an independent data set? If all
Paul Rubin wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
And a view of the dictionary is orders faster than creating a copy
of it (which is required to keep k0 from changing in your example).
If you're LUCKY, copying a dictionary is O(n),
There are ways to do it so you don't have to
Delaney, Timothy (Tim) wrote:
Plus copy-on-write isn't something you want in general - it's *much*
slower since it needs to copy the internal data every time it's
modified. The vast majority of uses of data structures does not involve
concurrent modification.
But copy-on-write in the presence
Scott David Daniels wrote:
Delaney, Timothy (Tim) wrote:
Plus copy-on-write isn't something you want in general - it's *much*
slower since it needs to copy the internal data every time it's
modified. The vast majority of uses of data structures does not
involve concurrent modification.
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
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes:
If you want an independent data set, you have to take a snapshot. For
the above, that's doing:
k0 = list(d.keys())
I don't understand. Why have .keys() at all, if it doesn't get you
an independent data set? If all you want is to iterate
