classification
Title: Give __len__() advice for "don't know"
Type: enhancement Stage:
Components: Documentation Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: benjamin.peterson, docs@python, georg.brandl, pitrou, rhettinger, tim_one
Priority: normal Keywords:

Created on 2005-09-06 15:37 by tim_one, last changed 2010-08-21 19:06 by BreamoreBoy.

Messages (7)
msg61205 - (view) Author: Tim Peters (tim_one) * (Python committer) Date: 2005-09-06 15:37
A class may wish to define __len__() despite that it 
doesn't know how many objects iterating an instance 
may produce.  The docs should give advice for this 
case.  They should also explicitly point out that the 
result of __len__() is generally taken to be a _hint_ 
(functions like map(), tuple(), etc., may preallocate 
space based on __len__()'s result, but adjust to the 
actual number of objects produced).

Tail end of a related thread:

<http://mail.zope.org/pipermail/zope3-dev/2005-
September/015599.html>
msg61206 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2005-09-07 05:24
Logged In: YES 
user_id=80475

FWIW, I had explored this topic at some length with Guido's
input and arrived at somewhat similar guidance. At any given
time, a dynamic object with a __len__() method should report
accurately or not at all (raising a TypeError).  Accurate
means that at that moment, len(d) == len(list(d)).  
Subsequent mutations may affect the length and the __len__()
method is expected to adjust accordingly.  For more notes on
the subject, see the module docstring for
Lib/test/test_iterlen.py

In the face of dynamic inputs, consumer functions like map()
must regard the reported lengths as estimates. However, that
should not lower the standards for objects reporting their
length.  That number should continue to have some meaning
such as the point-in-time invariant described above.
msg82294 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-02-17 02:13
I believe this bug is out of date with the advent of __length_hint__.
msg82296 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-02-17 02:30
It should still be documented that __len__ can be used for this purpose.

The __length_hint__ attribute is mainly for iterators because they are
not allowed to have a __len__ as that would affect their boolean value.
msg82359 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-02-17 19:27
If iterators don't want their boolean value to be messed up, couldn't
they simply use __bool__ for that?
msg82361 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-02-17 20:13
On Tue, Feb 17, 2009 at 1:27 PM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> If iterators don't want their boolean value to be messed up, couldn't
> they simply use __bool__ for that?

Since there is no base iterator class, that would complicate the API
and lead to subtle bugs. Personally, I don't think any iterators
should supported len() at all.
msg82399 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-02-18 00:35
Where would you prefer adding this documentation?
History
Date User Action Args
2010-08-21 19:06:04BreamoreBoysetassignee: georg.brandl -> docs@python

nosy: + docs@python
2009-02-18 00:35:08georg.brandlsetmessages: + msg82399
2009-02-17 20:13:28benjamin.petersonsetmessages: + msg82361
2009-02-17 19:27:13pitrousetnosy: + pitrou
messages: + msg82359
2009-02-17 02:30:42rhettingersetstatus: closed -> open
assignee: georg.brandl
resolution: out of date ->
messages: + msg82296
nosy: + georg.brandl
2009-02-17 02:13:33benjamin.petersonsetstatus: open -> closed
nosy: + benjamin.peterson
resolution: out of date
messages: + msg82294
2005-09-06 15:37:50tim_onecreate