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

[MRAB]

Dino Viehland wrote:
> Is there a reason or a rule by which CPython reports different error 
> message for different failures to subscript?
> 
>  
> 
> For example:
> 
>  
> 
>  >>> set()[2]
> 
> Traceback (most recent call last):
> 
>   File "<stdin>", line 1, in <module>
> 
> TypeError: 'set' object does not support indexing
> 
>  >>> class c(object): pass
> 
> ...
> 
>  >>> c()[2]
> 
> Traceback (most recent call last):
> 
>   File "<stdin>", line 1, in <module>
> 
> TypeError: 'c' object does not support indexing
> 
>  
> 
> But compare this to:
> 
>  
> 
>  >>> [].append[42]
> 
> Traceback (most recent call last):
> 
>   File "<stdin>", line 1, in <module>
> 
> TypeError: 'builtin_function_or_method' object is unsubscriptable
> 
>  >>> (lambda: 42)[42]
> 
> Traceback (most recent call last):
> 
>   File "<stdin>", line 1, in <module>
> 
> TypeError: 'function' object is unsubscriptable
> 
>  >>> property()[42]
> 
> Traceback (most recent call last):
> 
>   File "<stdin>", line 1, in <module>
> 
> TypeError: 'property' object is unsubscriptable
> 
>  
> 
> IronPython had a bug report that we were getting this wrong for set 
> objects and that “does not support indexing” was also a clearer error 
> message.  I’m wondering if there’s some reason why the different error 
> messages occur which I’m missing.   Otherwise I could switch to using 
> the more clear message or start marking types which should report the 
> unsubscriptable error.  Does anyone have any insights into this?
> 
I thought that the difference might be between iterable and non-iterable
objects, but then I'd expect the class 'c' to behave like the other
non-iterables. In fact, the result is different again if it's an
old-style class:

 >>> class c: pass

 >>> c()[2]

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
     c()[2]
AttributeError: c instance has no attribute '__getitem__'