[Python-ideas] Fw: accurate errors for "magic" methods

spir denis.spir at free.fr
Wed Apr 15 12:57:14 CEST 2009


Le Tue, 14 Apr 2009 23:35:22 -0700,
Chris Rebert <pyideas at rebertia.com> s'exprima ainsi:

[...]
> >> >
> >> > >>> A()['a']
> >> >
> >> > Traceback (most recent call last):
> >> >   File "<stdin>", line 1, in <module>
> >> > TypeError: 'A' object is unsubscriptable
> >> >
> >> >
> >> > (the difference being that A is new-style, while Values is
> >> > old-style.)
> >>
> >>
> >> Except that the error "object is unsubscriptable" might as well be in
> >> Klingon to most people, particularly newbies.
> >>
> >> (1) It's easy to misread it as "unscriptable", which is even more
> >> mysterious.
> >>
> >> (2) As far as I know, there's no tradition of describing key or index
> >> lookup as "subscripting" in Python. I've never noticed it in doc
> >> strings or the online docs, and after hanging around comp.lang.python
> >> extensively for years, I feel safe to say it's not a common term among
> >> even experienced Python developers. I suppose that there's a weak
> >> connection between index lookup and subscripts in mathematics.
> >>
> >> (3) The classic error message tells the newbie exactly what the error
> >> is: the object has no __getitem__ method. The new error message tells
> >> the newbie nothing useful. Given that obj is unsubscriptable, what
> >> needs to be done to make it subscriptable?
> >
> > +1
> >
> > And not just the newbie, either.  The experienced python programmer
> > looks at the original message and goes "ah ha".  The experienced python
> > programmer looks at the new message and has to _think about it_ before
> > understanding arrives.  I think that would be true even if you found a
> > better word than 'unsubscriptable'.  "Does not implement an item lookup
> > method" might work.  Or how about, 'Does not implement the Sequence or
> > Mapping interface'?
> >
> > But you know what?  Doing a google search for 'python mapping' gets you
> > the description of dictionaries, while doing a google search for 'python
> > __getitem__' gets you to the data model chapter that describes how the
> > mapping/sequence behavior is implemented via __getitem__.  The latter
> > is more useful even to the newbie, I think.
> >
> > So even if it looks ugly, I think the error message should mention
> > __getitem__.
> 
> I have gone ahead and filed a bug: http://bugs.python.org/issue5760
> 
> Cheers,
> Chris

Here's a copy of the suggeston:
================
Use exception chaining and rephrase the error message to get something like:

AttributeError: class 'A' has no attribute '__getitem__'
The above exception was the direct cause of the following exception:
TypeError: 'A' object does not support the 'get item' operator
================

Much better, I guess. But actually such errors often happen on objects for which a 'get item' operation simply makes no sense (because of another design or programming error). A typical case beeing None itself (see what I mean?). The remedy is rarely to add a __getitem__ method to a custom container class. Rather it is to check whether a container was properly returned by a previous operation:
   cont = ...
   try:
      result = cont[0]
   except AttributeError:
      raise ValueError("Cannot find...")

As a consequence, I still think that mentioning the notion of container is helpful, eg:
   TypeError: 'A' object is not a container able to support the 'get item' operator.

Also, what do you think of "item extraction" as an understandable wording for "use of []" or "call to __getitem__"(*).
   AttributeError: class 'A' has no attribute '__getitem__'
   The above exception was the direct cause of the following exception:
   TypeError: 'A' object is not a container able to support item extraction.

If ever such an idiom as "item extraction" is found correct, it could be reused in the ABC lexicon, for consistency. 

(*) An issue for finding a proper idiom is that getitem is also called for slicing. A single item is not a mini-slice.

Denis

------
la vita e estrany



More information about the Python-ideas mailing list