(original) (raw)

On Sun, Jul 15, 2012 at 9:18 AM, Benjamin Peterson <benjamin@python.org> wrote:
>> 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.

Length hints are very useful for \*any\* container implementation,
whether those containers are in the standard library or not. Just as
we exposed operator.index when \_\_index\_\_ was added, we should expose
an "operator.length\_hint" function with the following semantics:

def length\_hint(obj):
"""Return an estimate of the number of items in obj. This is
useful for presizing containers when building from an iterable.

If the object supports len(), the result will be exact.
Otherwise, it may over or underestimate by an arbitrary amount. The
result will be an integer >= 0.
"""
try:
return len(obj)
except TypeError:
try:
get\_hint = obj.\_\_length\_hint\_\_
except AttributeError:
return 0
hint = get\_hint()
if not isinstance(hint, int):
raise TypeError("Length hint must be an integer, not
%r" % type(hint))
if hint < 0:
raise ValueError("Length hint (%r) must be >= 0" % hint)
return hint

There's no reason to make pure Python container implementations
reimplement all that for themselves.

Cheers,
Nick.

\--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia