[Python-Dev] PEP 0424: A method for exposing a length hint

Stefan Behnel stefan_ml at behnel.de
Sun Jul 15 11:11:50 CEST 2012

Alex Gaynor, 15.07.2012 07:20:
> there's no way for the __lenght_hint__ to specify that
> that particular instance can't have a length hint computed.  e.g. imagine
> some sort of lazy stream that cached itself, and only wanted to offer a
> length hint if it had already been evaluated.  Without an exception to
> raise, it has to return whatever the magic value for length_hint is (in
> your impl it appears to be 0, the current _PyObject_LengthHint method in
> CPython has a required `default` parameter).  The PEP proposes using
> TypeError for that.

Yes, that's a major issue. I've been planning to add a length hint to
Cython's generator expressions for a while, but the problem is really that
in most cases it is only known at runtime if the underlying iterable has a
length hint, so propagating it needs a way to say "sorry, I thought I might
know, but I don't". It would be even better if this way was efficient.
Since we're at a point of making this an official protocol, why not change
the current behaviour and return -1 (or even just 0) to explicitly state
that "we don't know"?

The problem with an exception here is that it might have been raised
accidentally inside of the __length_hint__() implementation that is being
asked. Swallowing it just because it happened to be a TypeError rather than
something else may end up covering bugs. We had a similar issue with
hasattr() in the past.

Also, it would be nice if this became a type slot rather than requiring a
dict lookup and Python function call.


More information about the Python-Dev mailing list