| 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 "", line 1, in 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) *  |
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) * |
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) * |
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) * |
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) * |
Date: 2009-02-10 12:52 |
| Fixed in #5137. |
|
|