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__'
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
