Guido van Rossum wrote:
>
> [BDFL]
> > > The statement
> > >
> > > for <variable> in <object>: <block>
> > >
> > > should translate into this kind of pseudo-code:
> > >
> > > # variant 1
> > > __temp = <object>.newiterator()
> > > while 1:
> > > try: <variable> = __temp.next()
> > > except ExhaustedIterator: break
> > > <block>
> > >
> > > or perhaps (to avoid the relatively expensive exception handling):
> > >
> > > # variant 2
> > > __temp = <object>.newiterator()
> > > while 1:
> > > __flag, <variable = __temp.next()
> > > if not __flag: break
> > > <block>
>
> [MAL]
> > How about a third variant:
> >
> > #3:
> > __iter = <object>.iterator()
> > while __iter:
> > <variable> = __iter.next()
> > <block>
> >
> > This adds a slot call, but removes the malloc overhead introduced
> > by returning a tuple for every iteration (which is likely to be
> > a performance problem).
>
> Are you sure the slot call doesn't cause some malloc overhead as well?
Quite likely not, since the slot in question doesn't generate
Python objects (nb_nonzero).
> Ayway, the problem with this one is that it requires a dynamic
> iterator (one that generates values on the fly, e.g. something reading
> lines from a pipe) to hold on to the next value between "while __iter"
> and "__iter.next()".
Hmm, that depends on how you look at it: I was thinking in terms
of reading from a file -- feof() is true as soon as the end of
file is reached. The same could be done for iterators.
We might also consider a mixed approach:
#5:
__iter = <object>.iterator()
while __iter:
try:
<variable> = __iter.next()
except ExhaustedIterator:
break
<block>
Some iterators may want to signal the end of iteration using
an exception, others via the truth text prior to calling .next(),
e.g. a list iterator can easily implement the truth test
variant, while an iterator with complex .next() processing
might want to use the exception variant.
Another possibility would be using exception class objects
as singleton indicators of "end of iteration":
#6:
__iter = <object>.iterator()
while 1:
try:
rc = __iter.next()
except ExhaustedIterator:
break
else:
if rc is ExhaustedIterator:
break
<variable> = rc
<block>
> > Another possibility would be using an iterator attribute
> > to get at the variable:
> >
> > #4:
> > __iter = <object>.iterator()
> > while 1:
> > if not __iter.next():
> > break
> > <variable> = __iter.value
> > <block>
>
> Uglier than any of the others.
>
> > You might want to check out the counterobject.c approach I used
> > to speed up the current for-loop in Python 1.5's ceval.c:
> > it's basically a mutable C integer which is used instead of
> > the current Python integer index.
>
> > The details can be found in my old patch:
> >
> > http://starship.python.net/crew/lemburg/mxPython-1.5.patch.gz
>
> Ah, yes, that's what I was thinking of.
>
> > """ Generic object iterators.
> [...]
>
> Thanks -- yes, that's what I was thinking of. Did you just whip this
> up?
The file says: Feb 2000... I don't remember what I wrote it for;
it's in my lib/ dir meaning that it qualified as general purpose
utility :-)
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
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