@DimitrisJim, thanks for your PR! By analyzing the history of the files in this pull request, we identified @rhettinger, @serhiy-storchaka and @eliben to be potential reviewers.

Interesting issue!
What about PyErr_SetString(PyExc_ValueError, "sequence.index(x): x not in sequence"); (in abstract.c) ; PyErr_Format(PyExc_ValueError, "%R is not in range", ob); (only the truncation is missing) (in rangeobject.c) ?

@SylvainDe About abstract.c: From what I know, that isn't tested anywhere, I might be wrong but a core-dev would need to clarify that.
About the truncation in rangeobject.c: there's probably quite a number of those around but truncating all of them was beyond the scope of the issue. I merely unified all error messages on .index and .remove I could find; no need to fix unrelated issues and make the code-review harder for people :-)

@DimitrisJim Sure ! Thanks for the answer :-)

I'm not sure this is a good idea. Do we have any evidence that the current error messages are causing problems for users. At least some of this code is well over a decade old and I don't recall a single user complaint. In addition, I don't think we necessarily want to make %.100R the new norm except in cases where the original author thought is would be helpful.

Hi @rhettinger! Personally, I haven't seen any users facing problems due to the specific error message. This is probably because it is generally easy to use print before the offending call to get information on the value used or it might be included in the traceback if a literal was used.

On the other hand, it's a shame to have the information on what value was attempted to be removed/looked-up with remove and index readily available and not give it to the user. Doing so makes debugging errors easier and thankfully does it with very minor and non-intrusive changes to the code. This and the fact that no dissenting opinions existed on b.p.o made be think it might be a good change.

As for %.100R I'd agree and I'd be more than willing to roll-back the change to deque where I only made a change from %R to %.100R if, as the author, you think it might be too defensive and not helpful.