Alex Gaynor, 15.07.2012 00:11:

> CPython currently defines an ``__length_hint__`` method on several types, such
> as various iterators. This method is then used by various other functions (such
> as ``map``) to presize lists based on the estimated returned by
> ``__length_hint__``. Types can then define ``__length_hint__`` which are not
> sized, and thus should not define ``__len__``, but can estimate or compute a
> size (such as many iterators).
>
> Proposal
> ========
>
> This PEP proposes formally documenting ``__length_hint__`` for other
> interpreter and non-standard library Python to implement.
>
> ``__length_hint__`` must return an integer, and is not required to be accurate.
> It may return a value that is either larger or smaller than the actual size of
> the container. It may raise a ``TypeError`` if a specific instance cannot have
> its length estimated. It may not return a negative value.

I'd like to more visibly repeat my suggestion to make this a slot method
"tp_length_hint()" in extension types that returns a Py_ssize_t.

That suggests that a negative return value would have a special meaning
instead of relying on return values like NotImplemented. The Python wrapper
of that slot method could still implement a mapping for this.

Return values could be -1 for "don't know" and -2 for "infinite" at the C
level, and NotImplemented for "don't know" at the Python level. Not sure
about a good Python value for "infinite".

Maybe return -1 for "infinite" at both levels and -2/NotImplemented for
"don't know" in C/Python? That would suggest -3 to propagate exceptions at
the C level.