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.
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