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

MRAB python at mrabarnett.plus.com
Thu Sep 24 02:15:19 CEST 2009


Janzert wrote:
> Steven D'Aprano wrote:
>> On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
>>>> So I am +1 on unified the message and +1 on using the "does not
>>>> support indexing" one.
>>> I'd be +1 on the unified message as well - but it seems what that
>>> message should be may be contentious (and quite a bike shed
>>> discussion at that). The bug David linked to
>>> (http://bugs.python.org/issue5760) has a preference for subscript
>>> because that's what's used elsewhere in the language.
>> For what it's worth, "unsubscriptable object" seems to me to be 
>> mysterious to many newbies, and even a few non-newbies. It took me 
>> something like seven years of coding to stop reading it 
>> as "unscriptable object", and I'm sure I won't be the only one.
>>
>> As far as I can see, in practice, people talk about obj[i] as the item 
>> at index i, not the item at subscript i -- the term "subscript" in this 
>> context seems to be rare to non-existent except for the error message.
>>
>>
>>
> 
> How about if it's obj["item"]? To me the following makes complete sense,
> but then it seems that I may just be the odd one out.
> 
>>>> class A(object):
> ...     pass
> ...
>>>> a = A()
>>>> a[1]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'A' object is unindexable
>>>> a["a"]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'A' object is unsubscriptable
> 
I prefer "index" to "subscript" and "does not support foo" or "cannot be
fooed" to "is unfooable" (because, to me, "not" is more explicit than
"un-"). I also prefer the same term to be used irrespective of the
value used.


More information about the Python-Dev mailing list