Issue3729
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) * ![]() |
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. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:56:38 | admin | set | github: 47979 |
| 2009-02-10 12:52:53 | benjamin.peterson | set | status: open -> closed nosy: + benjamin.peterson resolution: fixed messages: + msg81545 |
| 2008-09-02 18:29:46 | hagen | set | files: - len_check2.diff |
| 2008-09-02 18:29:43 | hagen | set | files: - len_check.diff |
| 2008-09-02 18:29:24 | hagen | set | files:
+ len_check3.diff messages: + msg72360 |
| 2008-08-30 14:42:04 | georg.brandl | set | messages: + msg72196 |
| 2008-08-30 13:36:25 | hagen | set | messages: + msg72195 |
| 2008-08-29 19:56:45 | georg.brandl | set | nosy:
+ georg.brandl messages: + msg72153 |
| 2008-08-29 19:28:22 | amaury.forgeotdarc | set | messages: + msg72151 |
| 2008-08-29 16:18:56 | hagen | set | files:
+ len_check2.diff messages: + msg72145 |
| 2008-08-29 15:28:41 | hagen | set | messages: + msg72143 |
| 2008-08-29 15:15:28 | amaury.forgeotdarc | set | nosy:
+ amaury.forgeotdarc messages: + msg72142 |
| 2008-08-29 14:59:07 | hagen | create | |
