Dictionaries are not sequences. I wonder what order a user of for k,v in dict: (or whatever other of this proposal you choose) will expect...
The same order that for k,v in dict.items() will yield, of course.
And then people find out that the order has some sorting properties and start to use it... "how to sort a dictionary?" comes up again, every now and then.
I don't understand why you bring this up. We're not revealing anything new here, the random order of dict items has always been part of the language. The answer to "how to sort a dict" should be "copy it into a list and sort that." Or am I missing something?
Please also take into account that dictionaries are *mutable* and their internal state is not defined to e.g. not change due to lookups (take the string optimization for example...), so exposing PyDict_Next() in any to Python will cause trouble. In the end, you will need to create a list or tuple to iterate over one way or another, so why bother overloading for-loops w/r to dictionaries ?
Actually, I was going to propose to play dangerously here: the
for k:v in dict: ...
syntax I proposed in my previous message should indeed expose PyDict_Next(). It should be a big speed-up, and I'm expecting (though don't have much proof) that most loops over dicts don't mutate the dict.
Maybe we could add a flag to the dict that issues an error when a new key is inserted during such a for loop? (I don't think the key order can be affected when a key is *deleted*.)
You mean: mark it read-only ? That would be a "nice to have" property for a lot of mutable types indeed -- sort of like low-level locks. This would be another candidate for an object flag (much like the one Fred wants to introduce for weak referenced objects).
Yes. --Guido van Rossum (home page: http://www.python.org/~guido/)