[Python-Dev] More imformative iterator representations (original) (raw)
Raymond Hettinger raymond.hettinger at verizon.net
Tue Apr 6 21:22:19 EDT 2004
- Previous message: [Python-Dev] PEP 318: How I would implement decorators
- Next message: [Python-Dev] More imformative iterator representations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Armin's note reminded me that the only thing I do not like about using iterators is not being able to see their contents at the interactive prompt. 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 least imperfect solution I found was to replace the iterator with an equivalent object: firstfew=list(islice(it, 3)); it=chain(firstfew, it). Unfortunately, now the "it" variable is a chain object rather than the original iterator and the object id is different.
An alternative to the read-eval-print approach is providing a custom repr() method for the builtin iterators. The good news is that this approach is very clean. The bad news is that it won't help user defined iterators or builtin iterators like enumerate() that do not know their future until next() is called. So, this approach is only applicable to a few iterators; it is no problem for lists, tuples, dictionaries, sets, sequence iterators, xrange iterator objects, reversed objects, itertools.repeat(), itertools.count(), and collections.deque() iterators.
Eventhough this solution cannot be applied uniformly for all iterators, I think is worth considering for places where it does apply:
>>> reversed('abcdefgh')
reversed(['h', 'g', 'f', ...])
This could make iterators more pleasant to use interactively. What do you guys think?
Raymond Hettinger
Q&A:
Q: What if .next() is labor intensive to compute? A: It is only being proposed for objects where the entries are immediately accessible.
Q: Are there any other candidate output formats? A: Yes, we could add length information for a more mathematical style output:
reversed(['h', 'g', 'f', ... to 8 objects])
Q: What if .next() returns three objects whose representations consume a lot of visual space? A: This is not unique to iterators. The same issue occurs to a larger extent when displaying lists. It is sometimes a PITA but usually not a problem.
Q: What prevents enumerate(), imap(), izip(), etc. from implementing the more informative representations? A: They could, but it is messy to go through copy=list(islice(it,3)) and it=chain(copy,it) for every input.
Q: What if calling next() initiates some sort of activity that we wished to defer until later? A: This would be a rare situation for interactive work, but if known to be an issue, printing the repr() is easily avoided by making an assignment: _ = launch1000ships().
Q: Do you really want this? A: It is nice to have but not essential.
- Previous message: [Python-Dev] PEP 318: How I would implement decorators
- Next message: [Python-Dev] More imformative iterator representations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]