On Sun, Jul 29, 2012 at 6:11 PM, Alex Gaynor firstname.lastname@example.org wrote:
Guido van Rossum <guido <at> python.org> writes:
Looks good to me, so accepted.But why isn't it visible on python.org/dev/peps/
I just realized the text in the python.org repo did not match what I had locally. I've pushed what I intended to be the latest text, if everyone could take a new look at that I would be very grateful. Sorry for the mixup.
I look a careful look at what's in Hg (still totally different from what python.org displays) and am proposing a few editorial changes; please see the review at http://codereview.appspot.com/6447061
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?
- Did you mean to define operator.length_hint()?
- The default can be zero with no semantic impact, so I think there's no need to require the caller to specify a default.
- 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__().