| msg61205 - (view) |
Author: Tim Peters (tim.peters) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2009-02-18 00:35 |
| Where would you prefer adding this documentation? |
|
|
| msg173015 - (view) |
Author: Todd Rovito (Todd.Rovito) * |
Date: 2012-10-16 05:00 |
| For Python 3.4 attached is a patch as suggested by Raymond Hettinger. My suggestion is to put the patch in Doc/reference/datamodel.rst because if a user searches google.com for __len__ this is the first link in the list. I think this extra information is a valuable addition to the documentation. |
|
|
| msg173220 - (view) |
Author: Todd Rovito (Todd.Rovito) * |
Date: 2012-10-18 00:20 |
| New patch with a better reference to the source for the test case. This was suggested by PythonMentors list. I think the patch improves the documentation. This works on Python 3.4. |
|
|
| msg173366 - (view) |
Author: Todd Rovito (Todd.Rovito) * |
Date: 2012-10-20 04:57 |
| Changed the file name so it is clear that this patch goes with version 3.4. |
|
|
| msg173367 - (view) |
Author: Todd Rovito (Todd.Rovito) * |
Date: 2012-10-20 04:58 |
| Used the right patch file name this time... |
|
|
| msg173368 - (view) |
Author: Todd Rovito (Todd.Rovito) * |
Date: 2012-10-20 04:59 |
| This patch is for Python 2.7. |
|
|
| msg388694 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2021-03-14 23:02 |
| Looking at the patch years later, I'm thinking that this isn't needed or helpful. Not needed because users haven't reported any misunderstandings in the interim. Not helpful because the text looks forbidding and impenetrable, too much for a simple method like __len__(). I recommend closing this as out-of-date. As Benjamin noted, the advent of __length_hint__ has mostly made this issue go away. |
|
|