Tim Peters wrote:
[MAL]
... What we really want is iterators for dictionaries, so why not implement these instead of tweaking for-loops.
Seems an unrelated topic: would "iterators for dictionaries" solve the supposed problem with iteration order?
No, but it would solve the problem in a more elegant and generalized way. Besides, it also allows writing code which is thread safe, since the iterator can take special actions to assure that the dictionary doesn't change during the iteration phase (see the other thread about "making mutable objects readonly").
If you are looking for speedups w/r to for-loops, applying a different indexing technique in for-loops would go a lot further and provide better performance not only to dictionary loops, but also to other sequences.
I have made some good experience with a special counter object (sort of like a mutable integer) which is used instead of the iteration index integer in the current implementation.
Please quantify, if possible. My belief (based on past experiments) is that in loops fancier than
for i in range(n): pass
the loop overhead quickly falls into the noise even now.
I don't remember the figures, but these micor optimizations do speedup loops by a noticable amount. Just compare the performance of stock Python 1.5 against my patched version.
Using an iterator object instead of the integer + __getitem__ call machinery would allow more flexibility for all kinds of sequences or containers. ...
This is yet another abrupt change of topic, yes <0.9 wink>? I agree a new iteration *protocol* could have major attractions.
Not really... the counter object is just a special case of an iterator -- in this case iteration is over the IN. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/