[Python-Dev] More imformative iterator representations

[Michael Chermside]

Raymond writes:
> So, I posted an idea about changing the print part of the
> read-eval-print loop to display more information:
> 
> >>> enumerate('abcdefgh') 
> <enumerate object at 0x401a102c:  (0, 'a') (1, 'b') (2, 'c') ...>
> 
> There a couple of problems with the approach.  One is how to identify an
> iterator object -- the presence of __iter__() and next() is a good but
> not perfect indicator.
> 
> The other issue was trying to leave the iterator undisturbed while
> fetching the first three entries.

The issue of leaving the iterator undisturbed is more significant
than you think. It is an important feature of the iterator contract
that iterators are NOT asked to produce their values until the
iterator is actually USED. People take advantage of this by using
iterators when producing output that requires lots of resources
(like CPU).

For example, I sometimes write simple code which runs through very
large directories of logfiles and analyses the contents. Sometimes
it takes noticable time (1-5 min) per directory processed. So I
write an iterator which does one directory per invocation. I would
hate to have it take 3-15 minutes to skip ahead (and waste gobs
of memory keeping _3_ results in memory when it's never necessary
to keep more than 1 at once) just in order to pretty-print the
iterator. And yes, I do this in interactive mode.

I guess I wouldn't mind if certain built-in iterators did this...
list iterators, for instance, are easy. But I would object to any
scheme which tried to impose it on user-defined iterators. If the
user wants a nicely-printed iterator, they can override __repr__!

-- Michael Chermside