On Mon, Jul 30, 2012 at 9:51 AM, Guido van Rossum email@example.com 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.
-- --Guido van Rossum (python.org/~guido)