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__'
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4