M.-A. Lemburg wrote: > Brett Cannon wrote: > >> On Tue, Sep 22, 2009 at 20:08, R. David Murray <rdmurray at bitdance.com> wrote: >> >>> On Wed, 23 Sep 2009 at 02:01, MRAB wrote: >>> >>>> 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 >>>>>>>> >>>>> ... >>>>> >>> [....] >>> >>>>>>>> [].append[42] >>>>>>>> >>>>> Traceback (most recent call last): >>>>> File "<stdin>", line 1, in <module> >>>>> TypeError: 'builtin_function_or_method' 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__' >>>> >>> Looking at the source, these messages are generated from abstract.c, and >>> the difference appears to be whether or not the tp_as_sequence slot is >>> filled in or not. If it is, but there is no sq_item method, then >>> PySequence_GetItem gives the "does not support indexing" message. >>> If it isn't filled in, you get the 'not subscriptable"(*) message from >>> PyObject_GetItem. >>> >>> The logic appears to be, roughly, if an object does not have mapping >>> methods, or has them but does not have mp_subscript, and does have >>> sequence methods but does not have sq_item, then you get a 'does >>> not support indexing'. Otherwise you get 'not subscriptable'. >>> >>> The question is, is this a useful distinction, or is it an >>> implementation artifact? >>> >> Let's ignore history, which I bet is the reason for the distinction, >> and just look at the error messages; does the distinction make sense >> to a newbie? I would say no and that the "does not support indexing" >> error message is more useful. For expert programmers they could figure >> out the problem with either error message. The only help is if you are >> trying to debug a type, but I am willing to bet most of us didn't know >> the distinction at the C level until David looked it up. >> >> So I am +1 on unified the message and +1 on using the "does not >> support indexing" one. >> > > +1 as well. > Also +1. I had a friend (an experienced programmer) who started using Python recently. The cryptic nature of some of the error messages was a sore point with him. Michael > Note that the wording of error message has never been something > we guaranteed backwards compatibility for, so such changes are a > lot easier to implement than API changes. > > (I just hope that doctest doesn't rely on the message texts.) > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
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