(original) (raw)
On Mon, Jul 30, 2012 at 9:51 AM, Guido van Rossum <guido@python.org> wrote:
Also, I have a few content quibbles:
- Is it really worth flagging a negative return value with ValueError?
I'd just as well clip this to zero. What's the worry? That the
computed value is wrong? But it's only meant to be a hint, and why
would -1 be any more wrong than e.g. 1000000000?
This was done for consistency with len(), I'm not particularly attached to any behavior.
- Did you mean to define operator.length_hint()?
Of course :)
- The default can be zero with no semantic impact, so I think there's
no need to require the caller to specify a default.
I suppose that's fair.
- Most importantly: calling len(obj) and catching TypeError can only
be a substitute for the real implementation, which IMO ought to check
for the presence of a tp_len slot. Alas, checking hasattr(obj,
'__len__') doesn't quite cut it either, since this returns true for a
class object that defines a __len__ method for its instances (the
class itself doesn't have a length). Still, I worry that calling
len(obj) and catching all TypeErrors overspecifies the desired
behavior; what I *want* to happen is to check if there is a __len__
method, and if so, call it and let any exceptions bubble through. It
may be best to add a comment explaining that am implementation doesn't
have to follow the letter of the Python code in the PEP, in
particular, if obj *has* a __len__() method but calling it raises an
exception, then length_hint(obj) may (ought to?) pass this exception
on instead of calling obj.__length_hint__().
Seems reasonable, rather than try to spec that out precisely in the pseudocode (aka Python ;)) a note like you suggest sounds good.
Alex
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero