[Python-Dev] _length_cue() (original) (raw)

Raymond Hettinger python at rcn.com
Fri Feb 10 10:12:55 CET 2006

[Giovanni]

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 interactive prompt, they almost always either wrap it in a consumer function or they assign it to a variable. The case of typing just, "enumerate([1,2,3])", 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 window showing the locals or the watches. And it's pretty easy to add some debugging print statement to the code, run the program/test, find out that, hey, that function returns an iterator, go back and add a list() around it to find out what's inside. I would welcome if the iterator repr string could show, when possible, the next 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: http://mail.python.org/pipermail/python-dev/2004-April/044136.html

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 year).

Raymond

More information about the Python-Dev mailing list