The old error of tuple.index(x): x not in tuple seemed very confusing to me. It was also harder to quickly understand what the program was doing wrong. This saves people a second pass through the program under the debugger because they can just see what the invalid value was.

The reason I am explicitly calling repr instead of using %R is that I didn't want to call repr twice if I didn't need to. If people think that is fine the format can just be tuple.index(%R): %R not in tuple instead.

I'm wondering if including the whole "tuple.index(%R)" part is still necessary? The traceback will tell you what method you called, so wouldn't "%R not in tuple" be enough?

I agree, "%R in tuple" is enough information for me. This would also remove the need to manually repr the object.

As a more meta question: I have noticed that many error messages in the stdlib use PyErr_SetString, or choose to use the type name instead of the repr of the object. Is there a reason for this? I normally try to fill the error message with as much context as possible to make debugging easier. Is it a performance worry?

> Is it a performance worry?

It really depends on what people are doing with their down.  If indexing potentially missing values is common, there will be a performance impact.  

Also, the cost of a __repr__ varies wildly depending on the data (i.e. a collections.Counter instance has an expensive __repr__, decimal objects have computations to runs as well).

From a user point of view, a repr might be helpful or it might be disasterously lengthy (a webpage, a giant bytearray, a long list of tuples).

Personally, I would rather not do this PR which seems to have the view that the exception is an error condition as opposed to being a normal way to terminate a series of index() calls.

What is the rationale for the inconsistency between tuples and lists here?

().index(0)
ValueError: tuple.index(x): x not in tuple

[].index(0)
ValueError: 0 is not in list

In this simple artificial case, it seems clear to me that the list version (which is similar to the proposed change) is superior.

However, it is often not sufficient to use such cases as the basis for making a decision. Raymond raises some very good points.

In particular, I noticed that printing the repr quickly becomes unwieldy for more complex objects. For example, I tried the following:
[].index(''.join(chr(randrange(97, 97+26)) for _ in range(1000)))
[].index(Counter(randrange(10) for _ in range(10000)))

Also discussed in Issue 13349