<br><br><div class="gmail_quote">On Sat, Jul 14, 2012 at 10:16 PM, Nick Coghlan <span dir="ltr">&lt;<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Jul 15, 2012 at 9:18 AM, Benjamin Peterson &lt;<a href="mailto:benjamin@python.org">benjamin@python.org</a>&gt; wrote:<br>
&gt;&gt; Open questions<br>
&gt;&gt; ==============<br>
&gt;&gt;<br>
&gt;&gt; There are two open questions for this PEP:<br>
&gt;&gt;<br>
&gt;&gt; * Should ``list`` expose a kwarg in it&#39;s constructor for supplying a length<br>
&gt;&gt;   hint.<br>
&gt;&gt; * Should a function be added either to ``builtins`` or some other module which<br>
&gt;&gt;   calls ``__length_hint__``, like ``builtins.len`` calls ``__len__``.<br>
&gt;<br>
&gt; Let&#39;s try to keep this as limited as possible for a public API.<br>
<br>
</div>Length hints are very useful for *any* container implementation,<br>
whether those containers are in the standard library or not. Just as<br>
we exposed operator.index when __index__ was added, we should expose<br>
an &quot;operator.length_hint&quot; function with the following semantics:<br>
<br>
    def length_hint(obj):<br>
        &quot;&quot;&quot;Return an estimate of the number of items in obj. This is<br>
useful for presizing containers when building from an iterable.<br>
<br>
        If the object supports len(), the result will be exact.<br>
Otherwise, it may over or underestimate by an arbitrary amount. The<br>
        result will be an integer &gt;= 0.<br>
        &quot;&quot;&quot;<br>
        try:<br>
            return len(obj)<br>
        except TypeError:<br>
            try:<br>
                get_hint = obj.__length_hint__<br>
            except AttributeError:<br>
                return 0<br>
            hint = get_hint()<br>
            if not isinstance(hint, int):<br>
                raise TypeError(&quot;Length hint must be an integer, not<br>
%r&quot; % type(hint))<br>
            if hint &lt; 0:<br>
                raise ValueError(&quot;Length hint (%r) must be &gt;= 0&quot; % hint)<br>
            return hint<br>
<br>
There&#39;s no reason to make pure Python container implementations<br>
reimplement all that for themselves.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span></blockquote></div><br>Sounds reasonable to me, the only issue with your psuedocode (err... I mean Python ;)), is that there&#39;s no way for the __lenght_hint__ to specify that that particular instance can&#39;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.<div>
<br></div><div>Anyways that code looks good, do you want to add it to the PEP?</div><div><br></div><div>Alex<br clear="all"><div><br></div>-- <br>&quot;I disapprove of what you say, but I will defend to the death your right to say it.&quot; -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
&quot;The people&#39;s good is the highest law.&quot; -- Cicero<br><br>
</div>