[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
