[Python-Dev] _length_cue()

[Raymond Hettinger]

[Armin Rigo]
> It was replaced by an optional undocumented method called _length_cue(),
> which would be used to guess the number of remaining items in an
> iterator, for performance reasons.
>
> I'm worried about the name.  There are now exactly two names that behave
> like a special method without having the double-underscores around it.
> IMHO for safety reasons we need to stick double-underscores around this
> name too, e.g. __length_cue__().

The single underscore was meant to communicate that this method is private 
(which is why it is undocumented).  Accordingly, the dir() function is smart 
enough to omit the method from its listing (which is a good thing).

We follow similar naming conventions in pure Python library code.  OTOH, 
this one is a bit different in that it is not truly private; rather, it is 
more like a friend method used internally for various tools to be able to 
communicate with each other.  If you change to a double underscore 
convention, you're essentially making this a public protocol.

IMHO, the "safety reasons" are imaginary -- the scenario would involve 
subclassing one of these builtin objects and attaching an identically named 
private method.

All that being said, I don't feel strongly about it and you guys are welcome 
to change it if offends your naming convention sensibilities.


[Andrew Koenig]
> Might I suggest that at least you consider using "hint" instead of "cue"?

Personally, I prefer "cue" which my dictionary defines as "a signal, hint, 
or suggestion".   The alternate definition of "a prompt for some action" 
applies equally well.

Also, to my ear, length_hint doesn't sound right.

I'm -0 on changing the name.  If you must, then go ahead.


[Armin Rigo]
> BTW the reason I'm looking at this is that I'm considering adding
> another undocumented internal-use-only method, maybe __getitem_cue__(),
> that would try to guess what the nth item to be returned will be.  This
> would allow the repr of some iterators to display more helpful
> information when playing around with them at the prompt, e.g.:
>
>>>> enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596])
> <enumerate (0, 3.1), (1, 3.14), (2, 3.141),... length 6>

At one point, I explored and then abandoned this idea.  For objects like 
itertools.count(n), it worked fine -- the state was readily knowable and the 
eval(repr(obj)) round-trip was possible.  However, for tools like 
enumerate(), it didn't make sense to have a preview that only applied in a 
tiny handful of (mostly academic) cases and was not evaluable in any case.

I was really attracted to the idea of having more informative iterator 
representations but learned that even when it could be done, it wasn't 
especially useful.  When someone creates an iterator at the interactive 
prompt, they almost always either wrap it in a consumer function or they 
assign it to a variable.  The case of typing just, "enumerate([1,2,3])", 
comes up only once, when first learning was enumerate() does.


Raymond