raymond.hettinger at verizon.net
Wed Feb 8 21:02:21 CET 2006
> 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
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.
> 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.
> 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.
More information about the Python-Dev