[issue3729] SystemError on calling len() if __len__() doesn't return an int

Benjamin Peterson added the comment: Fixed in #5137. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Changes by Hagen Fürstenau <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11308/len_check2.diff ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Changes by Hagen Fürstenau <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11307/len_check.diff ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: 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. Added file: http://bugs.python.org/file11

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Georg Brandl <[EMAIL PROTECTED]> added the comment: 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. ___ Python tracker <[EMAIL PROTECTED]>

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: 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? ___ Python tracker <[EMAIL PROTE

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Georg Brandl <[EMAIL PROTECTED]> added the comment: 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_ssiz

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: 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 ret

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: 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! ;-) Added file: http://bugs.python.org/file11308/len_check2.d

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: 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. ___

[issue3729] SystemError on calling len() if __len__() doesn't return an int

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: What about using PyNumber_AsSsize_t? it uses PyNumber_Index to accept integral-like types, and refuses floats. -- nosy: +amaury.forgeotdarc ___ Python tracker <[EMAIL PROTECTED]>

[issue3729] SystemError on calling len() if __len__() doesn't return an int

New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: On Python 3.0: >>> class C: ... def __len__(self): return "foo" ... >>> len(C()) Traceback (most recent call last): File "", line 1, in SystemError: Objects/longobject.c:433: bad argument to internal function On Python 2.6 the beh