[Python-3000] Weird error message from bytes type
ncoghlan at gmail.com
Mon Feb 26 11:10:36 CET 2007
Guido van Rossum wrote:
> Please give the poor function a break. It was added to 2.5 and used
> only for indexing there. In 3.0 it is more generally useful (I want to
> use it whenever an int is needed). but in our pre-alpha code the error
> messages haven't been fixed yet. That's the whole story.
A couple of locations in the 2.5 standard library actually had to deal
with the same problem. They currently make their own calls to
PyIndex_Check() in order to override the default error message. This
slice_indices (sliceobject.c) also uses PyNumber_AsSsize_t to check the
length argument that is passed in, but it just allows the PyNumber_Index
error message to flow through:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'str' object cannot be interpreted as an index
> On 2/25/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> But by calling __index__ and giving error messages about
>> indexes, PyInt_AsSsize_t seems to be assuming that the
>> value is going to be used as an index.
>> If that's the true purpose of PyInt_AsSsize_t, then it
>> shouldn't be getting called in this situation.
>> If it's not, then it shouldn't be giving error messages
>> that talk about indexes, and there should be another
>> API such as PyObject_AsIndex for values that really
>> are going to be used as indexes.
Generating a different error message when passing invalid types to
PyNumber_AsSsize_t (as opposed to PyNumber_Index) wasn't particularly
high on the to-do list when we were trying to fix the __index__()
clipping bugs for the 2.5 release - the exception raised by the eventual
implementation was of the correct type, even if the message wasn't
perfect. Further complicating a C API that was already somewhat complex
(a type checking function, plus two different conversion functions, one
with an extra argument relating to overflow handling) didn't seem to be
a desirable thing to do.
With additional usage in non-index contexts (and a bit more time to do
the work!), then it probably makes sense to modify PyNumber_Index and
PyNumber_AsSsize_t to call a common static function which allows them to
specify different format strings for the type error.
However, given that the error message has to make sense even when the
object involved is a float, finding appropriate wording that doesn't
mention the __index__ slot is somewhat challenging. For example, simply
replacing 'index' with 'integer' could lead to a different kind of
TypeError: 'float' object cannot be interpreted as an integer
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-3000