[ python-Feature Requests-1283110 ] Give __len__() advice for "don't know"

SourceForge.net noreply at sourceforge.net
Wed Sep 7 07:24:59 CEST 2005


Feature Requests item #1283110, was opened at 2005-09-06 10:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give __len__() advice for "don't know"

Initial Comment:
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>

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-07 00:24

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470


More information about the Python-bugs-list mailing list