This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: __getitem__ error message hard to understand
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.0, Python 3.1, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: cvrebert, georg.brandl, terry.reedy
Priority: normal Keywords:

Created on 2009-04-15 06:32 by cvrebert, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg85983 - (view) Author: Chris Rebert (cvrebert) * Date: 2009-04-15 06:32
Prompted by
http://mail.python.org/pipermail/python-ideas/2009-April/004048.html

The current error message issued when trying to use the get item ([])
operator on an object that does not define __getitem__ can be hard to
understand:

>>> class A(object): pass
...
>>> A()['a']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'A' object is unsubscriptable

Problems observed:
- "unsubscriptable" is easily misread in haste as "unscriptable", which
can be quite confusing, especially to newbies
- "subscripting" is not frequently used to describe the [] operator,
making the message more difficult to decipher (again, esp. for newbies)
- the underlying lack of a __getitem__ method is not mentioned, thus not
making it obvious how to remedy the error

Suggestion:
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

Similar changes should be made to __setitem__ & __delitem__.
msg86105 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-04-18 07:29
As I said on the python-ideas discussion, which definitely did *not*
come to consensus, I disagree with this suggestion.  To repeat and
expand on what I said there:

1. 'unsubscriptable' could instead be changed to 'not subscriptable'.

2. 'subscription' *is* the way Python describes the use of [].
"""A subscription selects an item of a sequence (string, tuple or list)
or mapping (dictionary) object:

subscription ::=  primary "[" expression_list "]"
"""
'array subscript' (from C, for example) is a standard term used for
decades in computer languages.  It is appropriate since a[i] is one
standard single-text-line replacement for a<typographic subscript>i when
one cannot actually 'type' a subscript.  It *is* a way of representing a
subscript, just as i**j is an in-line way of representing a superscript
exponent, which we still call an exponent in spite of it not being
'raised'.  Both constitute visible markup that is part of the compromise
in representing 2D typography with a 1D stream of characters.  Using '/'
for division (and fractions) is another.

3. Python error message generally do not and I think should not mention
the special method implementation that underlies surface level errors. 
In this particular case, the remedy to mistakenly trying to subscript
something is to not do that.  I think mentioning __getitem__ would be a
distraction.  One generally *cannot* just go around adding it.
msg86110 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-04-18 08:31
I concur. I changed "unsubscriptable" to "not subscriptable" in r71696.
History
Date User Action Args
2022-04-11 14:56:47adminsetgithub: 50010
2009-04-18 08:31:49georg.brandlsetstatus: open -> closed

nosy: + georg.brandl
messages: + msg86110

resolution: fixed
2009-04-18 07:29:09terry.reedysetnosy: + terry.reedy
messages: + msg86105
2009-04-15 06:32:10cvrebertcreate