Make TypeError message less ambiguous

[coyot]

BPO	35077
Nosy	@rhettinger, @terryjreedy, @srinivasreddy, @tirkarthi
PRs	bpo-35077: Make error message on string object less ambiguous #10132

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-10-26.15:52:43.478>
labels = ['type-feature', '3.10']
title = 'Make TypeError message less ambiguous'
updated_at = <Date 2021-09-24.17:31:16.599>
user = 'https://bugs.python.org/coyot'

bugs.python.org fields:

activity = <Date 2021-09-24.17:31:16.599>
actor = 'xtreak'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2018-10-26.15:52:43.478>
creator = 'coyot'
dependencies = []
files = []
hgrepos = []
issue_num = 35077
keywords = ['patch']
message_count = 11.0
messages = ['328565', '328567', '328580', '328587', '328596', '328597', '328598', '328604', '328834', '387630', '402579']
nosy_count = 5.0
nosy_names = ['rhettinger', 'terry.reedy', 'thatiparthy', 'xtreak', 'coyot']
pr_nums = ['10132']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue35077'
versions = ['Python 3.10']

[coyot]

The TypeError message:

TypeError: string indices must be integers

is ambiguously written. While some may understand the intent, others will read it as confusingly saying that strings must be integers since dicts among other things do have string indices. Suggest changing the message to:

TypeError: indices of strings must be integers

[srinivasreddy]

+1.

In my early days of python programming i was confused of this message.

[tirkarthi]

Thanks for the report. Error message changes are generally done on master and not back ported. I am removing 3.5 which is security fixes only mode and adding 3.8 . There are other errors of similar format but indicate the wrong type in the error message like list indices.

$ ./python.exe
Python 3.8.0a0 (heads/bpo31177-dirty:19986202a8, Oct 26 2018, 22:19:23)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> [1]['1']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers or slices, not str

I think we should also assert the error message in test_slice (Lib/test/string_tests.py) if there is a change.

Thanks Serhiy, I was about to add Raymond too who might have thoughts on the wording :)

[coyot]

You're welcome. I filed against 3.5 because that's what I have in our env at the moment and I couldn't test and thus assert the issue in later versions.

Happy to see the problem addressed more generally.

The abstraction of the problem is the ambiguity in English between nouns used as adjectives and their groupings: (noun phrase) versus (noun as adjective)(noun). Using "X of Y" rather than (XY) or (X)(Y) resolves the ambiguity.

[terryjreedy]

I have a mixed opinion of this. On the one hand, 'string index', taken out of context, *is* ambiguous. (In the context of the TypeError message, it took me a minute to see the string-index interpretation.) On the other hand, dicts do not have indices. They have keys. So only the 'index of string' interpretation makes sense.

Is there anything in the docs that suggests that a mapping subscript can be called an 'index' in addition to 'key'?

It would be nicer if this TypeError message also included 'not x', but there may be an issue that the type x info is lost.

[terryjreedy]

I checked a bit. All the 'index' entries in the index are about sequences. However, https://docs.python.org/3/reference/datamodel.html has this abstract (non-Python) description:

"Mappings
These represent finite sets of objects indexed by arbitrary index sets. The subscript notation a[k] selects the item indexed by k from the mapping a; ...
Dictionaries
These represent finite sets of objects indexed by nearly arbitrary values."

I personally would prefer 'keyed' or 'subscripted' and 'key'to prevent confusion. The entry then switches to the usual Python term 'key'.

"The only types of values not acceptable as keys ... a key’s hash value ... used for keys ..."

https://docs.python.org/3/library/stdtypes.html#mapping-types-dict uses 'index' once as a verb, otherwise uses 'key'.

[coyot]

The problem I have with "So only the 'index of string' interpretation makes sense." is that by the time a developer has that understanding, they won't get this error. So it's fine and logical to say from the behind-the-scenes view that only sequences talk about indices, but that's not helpful to the confused developer who gets this message. The point of error messages should be to clearly indicate the problem and solution, not rely on the developer having a global understanding of error messages.

So, rather than defend the current practice, I ask if there are arguments against "X of Y". Is there some context in which that is confusing?

[terryjreedy]

Aside from the effort of making a change correct and consistent across our code, error message changes often breaks user code and tests that depend on the current wording. So there must be sufficient benefit to overcome the cost. (The user breakage cost is why we nearly always wait for the next version to make such changes.)

[coyot]

Sure, this can wait to the next release. I don't see it as groundshatteringly ;) urgent.

[coyot]

3.8 has come and gone, resubmitting this for 3.10

[tirkarthi]

https://bugs.python.org/issue44110 did some improvements to error message to include type.