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

[Benjamin Peterson]

2012/7/14 Alex Gaynor <alex.gaynor at gmail.com>:
>
>
> On Sat, Jul 14, 2012 at 4:18 PM, Benjamin Peterson <benjamin at python.org>
> wrote:
>>
>> 2012/7/14 Alex Gaynor <alex.gaynor at gmail.com>:
>> >
>> > 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.
>>
>> And what happens if you return a negative value?
>>
>
> ValueError, the same as with len.

CPython will probably have to updated to not ignore it if you return "melons".

>
>>
>> >
>> > Rationale
>> > =========
>> >
>> > Being able to pre-allocate lists based on the expected size, as
>> > estimated by
>> > ``__length_hint__``, can be a significant optimization. CPython has been
>> > observed to run some code faster than PyPy, purely because of this
>> > optimization
>> > being present.
>> >
>> > Open questions
>> > ==============
>> >
>> > There are two open questions for this PEP:
>> >
>> > * Should ``list`` expose a kwarg in it's constructor for supplying a
>> > length
>> >   hint.
>> > * Should a function be added either to ``builtins`` or some other module
>> > which
>> >   calls ``__length_hint__``, like ``builtins.len`` calls ``__len__``.
>>
>> Let's try to keep this as limited as possible for a public API.
>>
>
> Sounds reasonable to me!  Should we just go ahead and strip those out now?

Certainly.


-- 
Regards,
Benjamin