python at rcn.com
Fri Feb 10 10:12:55 CET 2006
>> I was really attracted to the idea of having more informative iterator
>> representations but learned that even when it could be done, it wasn't
>> especially useful. When someone creates an iterator at the
>> prompt, they almost always either wrap it in a consumer function or
>> assign it to a variable. The case of typing just,
>> comes up only once, when first learning was enumerate() does.
> On the other hand, it's very common to see the iterator in the debug
> showing the locals or the watches. And it's pretty easy to add some
> print statement to the code, run the program/test, find out that, hey,
> function returns an iterator, go back and add a list() around it to find
> what's inside.
> I would welcome if the iterator repr string could show, when possible, the
> couple of elements.
Sorry, that's a pipe-dream. Real use-cases for enumerate() don't usually
have the luxury of having an argument that is a sequence. Instead, you have
to run the iteration a few steps to see what lies ahead. In general, this
isn't always possible (stdin for example) or desirable (where the iterator
is time consuming or memory intensive and so shouldn't be run unless the
value is actually needed) or may even be a disaster (if the iterator
participates in co-routine style code that expects to be passing control
back and forth between multiple open iterators). IOW, you cannot safely run
an iterator a few steps in advance, save-up the results for display, and
then expect everything else to work right.
I spent a good time of time pursuing this mirage, but there was no water:
AFAICT, the only way to achieve the effect you want is to get an environment
where all iterators are designed around an API that supports being run
forward and backward (such as the one demonstrated by Armin at PyCon last
More information about the Python-Dev