[Python-Dev] unsubscriptable vs object does not support indexing (original) (raw)

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 tpassequence slot is filled in or not. If it is, but there is no sqitem method, then PySequenceGetItem gives the "does not support indexing" message. If it isn't filled in, you get the 'not subscriptable"(*) message from PyObjectGetItem.

The logic appears to be, roughly, if an object does not have mapping methods, or has them but does not have mpsubscript, and does have sequence methods but does not have sqitem, 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