[Python-Dev] unsubscriptable vs object does not support indexing

Dino Viehland dinov at microsoft.com
Wed Sep 23 06:23:59 CEST 2009


R. David Murray wrote:
> Looking at the source, these messages are generated from abstract.c,
> and the difference appears to be whether or not the tp_as_sequence slot
> is filled in or not.  If it is, but there is no sq_item method, then
> PySequence_GetItem gives the "does not support indexing" message.
> If it isn't filled in, you get the 'not subscriptable"(*) message from
> PyObject_GetItem.
> 
> The logic appears to be, roughly, if an object does not have mapping
> methods, or has them but does not have mp_subscript, and does have
> sequence methods but does not have sq_item, then you get a 'does not
> support indexing'.  Otherwise you get 'not subscriptable'.
> 
> The question is, is this a useful distinction, or is it an
> implementation artifact?

First on the useful distinction: for better or worse users do seem to
have an affinity towards CPython's error messages and especially so 
when they're better than ours :).  But I certainly hope no one is taking 
a dependency on them by parsing them or anything like that such that it
would actually break someone's program.  So basically I regard all
error messages as implementation artifacts but I have no problem matching
them if it'll make someone happier and it's not too crazy to do it. 

That being said there does seem to be a useful distinction here.  It
sounds like the idea here is to report a better error message when
something is more collection like than a full blown sequence - in
particular I'm thinking of .NET's ICollection and Java's Collection 
interfaces that are very sequence like but don't support getting 
elements by index.

The only oddity in the error message to me is that user defined objects 
are effectively always treated as sequences.  That's completely an
implementation artifact but I'm going to copy it too because it's easy,
may prevent another bug report, and checking for all the various 
sequence methods seems like unnecessary overkill.

Thanks for the information!



More information about the Python-Dev mailing list