[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 


More information about the Python-Dev mailing list