[Python-3000] Weird error message from bytes type

[Nick Coghlan]

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 
happens in:
   sequence_repeat (abstract.c)
   _GetMapSize (mmapmodule.c)

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:

.>>> slice(2).indices('1')
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 
confusion:
   TypeError: 'float' object cannot be interpreted as an integer

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org