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

Raymond Hettinger python at rcn.com
Thu Feb 9 03:21:02 CET 2006

[Armin Rigo]

Hi Raymond, . . . This means that lengthcue() 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 lengthhint or lengthcue? :-)

I prefer length_cue unless someone has a strong objection.

And does anyone objects about getitemhint or getitemcue? Maybe lookaheadhint or lookaheadcue?

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