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__'