[Python-Dev] _length_cue()
Raymond Hettinger
python at rcn.com
Thu Feb 9 03:21:02 CET 2006
[Armin Rigo]
> Hi Raymond,
. . .
> This means that _length_cue() is at the moment a special method, in the
> sense that Python can invoke it implicitely.
Okay, that makes sense. Go ahead and make the swap.
> This said, do we vote for __length_hint__ or __length_cue__? :-)
I prefer __length_cue__ unless someone has a strong objection.
> And does anyone objects about __getitem_hint__ or __getitem_cue__?
> Maybe __lookahead_hint__ or __lookahead_cue__?
No objections here though I do question the utility of the protocol. It is
going to be difficult to find pairs of objects (one providing the lookahead
value and the other consuming it) that can make good use of the protocol.
Outside of those unique pairings, there is no value at all. Thinking back
over the code I ever seen, I cannot think of one case where the would have
been helpful (except for the ill-fated adventure of trying to make iterators
have more informative __repr__ methods).
Before putting this in production, it would probably be worthwhile to search
for code where it would have been helpful. In the case of __length_cue__,
there was an immediate payoff.
Value pre-fetching has more utility in an environment where the concept is
used everywhere (such as your lightning demo at PyCon last year where you
ran iterators forwards/backwards and do tricks with infinite iterators).
Outside of such an environment, I think it is going to be use-case
challenged.
Raymond
More information about the Python-Dev
mailing list