This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: SystemError on calling len() if __len__() doesn't return an int
Type: behavior Stage:
Components: Versions: Python 3.0, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, benjamin.peterson, georg.brandl, hagen
Priority: normal Keywords: patch

Created on 2008-08-29 14:59 by hagen, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
len_check3.diff hagen, 2008-09-02 18:29 patch fixing the SystemError and clipping to sys.maxsize, adds tests
Messages (10)
msg72141 - (view) Author: Hagen Fürstenau (hagen) Date: 2008-08-29 14:59
On Python 3.0:

>>> class C:
...     def __len__(self): return "foo"
...
>>> len(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/longobject.c:433: bad argument to internal function


On Python 2.6 the behaviour is different for old and new-style classes,
with old-style classes giving the more informative error message and
both accepting (and truncating) floats.

I attached a patch for Python 3.0, which refuses everything but ints and
gives an informative error message. Or does the float-truncating
behaviour of Python 2.x need to be preserved?
msg72142 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-08-29 15:15
What about using PyNumber_AsSsize_t? it uses PyNumber_Index to accept
integral-like types, and refuses floats.
msg72143 - (view) Author: Hagen Fürstenau (hagen) Date: 2008-08-29 15:28
Sounds ok, but then you get a more generic "object cannot be interpreted
as an integer" at the point where len() is called, instead of the
clearer "__len__() should return an int". I'm not sure if this could be
confusing.
msg72145 - (view) Author: Hagen Fürstenau (hagen) Date: 2008-08-29 16:18
Of course we can do both: Accept integral-like types and reset the
exception text. The new patch does this and adds a test for the new
behaviour.

Review carefully - I'm a newbie! ;-)
msg72151 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-08-29 19:28
Not bad! some remarks though:
- It's better to avoid the "expensive" call to PyErr_Occurred() when
possible. Here, an exception is set if (and only if) len==-1.
For example, it is enough to add these lines after the "__len__() should
return >= 0" message:

+		else if (PyErr_ExceptionMatches(PyExc_TypeError))
+			PyErr_SetString(PyExc_TypeError, 
+					"__len__() should return an int");

- Please clarify (that is: add tests for) the case where __len__ returns
1<<50 or -1<<50. If I remember correctly, PyNumber_AsSsize_t(res, NULL)
clips the values to MAXINT. Is this wanted?
msg72153 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-08-29 19:56
That is *not* wanted. We had a discussion on the list about changing the
return value of the sq_length slot to allow larger lengths to be
reported, and while I don't recall why this wasn't done, I do recall
that the consensus was that if Py_ssize_t remains, len() should raise
rather than lie for larger values-
msg72195 - (view) Author: Hagen Fürstenau (hagen) Date: 2008-08-30 13:36
In the latest list message I could find Guido wanted len() to lie:

http://mail.python.org/pipermail/python-3000/2008-May/013387.html

Has this been resolved in issue 2723?
msg72196 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-08-30 14:42
True. However, it's no pronouncement either. I suggest bringing it up on
the list again; probably other people would want to voice their opinions
too.
msg72360 - (view) Author: Hagen Fürstenau (hagen) Date: 2008-09-02 18:29
There seems to be a pronouncement now
(http://mail.python.org/pipermail/python-3000/2008-September/014692.html),
so I'm attaching a patch which clips to sys.maxsize and includes
Amaury's suggestions.
msg81545 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-02-10 12:52
Fixed in #5137.
History
Date User Action Args
2022-04-11 14:56:38adminsetgithub: 47979
2009-02-10 12:52:53benjamin.petersonsetstatus: open -> closed
nosy: + benjamin.peterson
resolution: fixed
messages: + msg81545
2008-09-02 18:29:46hagensetfiles: - len_check2.diff
2008-09-02 18:29:43hagensetfiles: - len_check.diff
2008-09-02 18:29:24hagensetfiles: + len_check3.diff
messages: + msg72360
2008-08-30 14:42:04georg.brandlsetmessages: + msg72196
2008-08-30 13:36:25hagensetmessages: + msg72195
2008-08-29 19:56:45georg.brandlsetnosy: + georg.brandl
messages: + msg72153
2008-08-29 19:28:22amaury.forgeotdarcsetmessages: + msg72151
2008-08-29 16:18:56hagensetfiles: + len_check2.diff
messages: + msg72145
2008-08-29 15:28:41hagensetmessages: + msg72143
2008-08-29 15:15:28amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg72142
2008-08-29 14:59:07hagencreate