[Python-Dev] Re: Sets: elt in dict, lst.include
Wed, 31 Jan 2001 13:08:15 +0100
Tim Peters wrote:
> > ...
> > 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
> > 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):
> 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.
Python Pages: http://www.lemburg.com/python/