Yes, this is what he's saying. Its not broken, just a bit different.
After all, you dont have a problem with:
lst = [1, 2, 3]
ptr = lst
lst.append(4) # this changes ptr
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
[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 copy, but the dict
Ooh, can you point me to them? This sounds very interesting.
The only way I can think of doing it is to have some fun with pointers
and not make the final copy until a change is made to the table. I'd
love to read about an algoritm which can get around this! I feel so
behind in the times, I
The meaning of dict.keys, etc, will not change for the 2.x series. For
3.0, I believe that Guido already intends that .keys() no longer return a
separate list. For one thing, a major, if not the main use, of the method
is for iteration, as in 'for keys in d.keys():'. For this, creating and
[EMAIL PROTECTED] wrote:
This has been bothering me for a while. Just want to find out if it
just me or perhaps others have thought of this too: Why shouldn't the
keyset of a dictionary be represented as a set instead of a list?
There has been much discussion of this on the Python-3000
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)
