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

Raymond Hettinger raymond.hettinger at verizon.net
Wed Feb 8 21:02:21 CET 2006

[Armin Rigo]

It was replaced by an optional undocumented method called lengthcue(), 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. lengthcue().

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 getitemcue(), 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

More information about the Python-Dev mailing list