> 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.
> 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*.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4