Currently: >>> l=[]; l[1] # 3.0.1
...
IndexError: list index out of range

Assuming that negative indexes are converted before the range test is
made, I would like to see
"IndexError: list index 1 not in range(0)", ie,
"IndexError: list index {0} not in range({1})".format(<index>,
len(<sequence>)).

The 'in' operator still works with Py3 range objects, so the suggested
Python-level check is still valid.

I did not add 2.6/3.0 only because I don't know if improved error
messages are acceptable in bug-fix releases.

Same request for other sequence IndexError messages:
>>> t=(); t[0]
IndexError: tuple index out of range

>>> s=''; s[0] # 3.0
IndexError: string index out of range

>>> b=b''; b[0]
IndexError: index out of range # *** 'bytes' uniquely missing here ***

>>> ba=bytearray(b); ba[0]
IndexError: bytearray index out of range

Is the check factored out as a macro (or function) so one change would
change all of these?

Similar errors with dict (tersely) give the bad key already:
>>> d={}; d[1]
...
KeyError: 1

The may be superficially similar to request bpo-654558, but that was vague
and was closed as a duplicate of bpo-569574, which is definitely about a
different issue. I did not see anything else in the search results.

This issue was discussed two years ago in this thread:

http://mail.python.org/pipermail/python-list/2006-December/588224.html

Most of the messages under that subject are noise about politeness or
lack thereof (including a post by the submitter of this issue trying to
get people to be reasonable!), but an actual patch was posted as well:

http://mail.python.org/pipermail/python-list/2006-December/588377.html

The patch addresses only one object type, but does demonstrate a pattern
that might be usable in general. A concern was raised about the
generality of the function proposed, as well as the performance
implications of calling it.

I have not tried to apply the patch to the current trunk, but from a
quick look it doesn't seem like the source has changed much. Since the
problem turns out to be a lot less trivial than it seems like it should
be, the patch is a good reference in any case.

See also bpo-1182143.

This issue is about formatting a value into an error message.
bpo-1182143 is about adding values that have already been formatted into an
error message to the resulting exception object. If this suggestion
were implemented, then IndexError would be added to the exceptions
covered by bpo-1182143

Patches to mailing lists tend to get lost. Thank you for finding
Bjourne's. I have invited him (at the email then given) to update it and
attach it here.

I've seen his patch and am working on my own variant that also attaches
the index value as a separate field in the args tuple. The problem may
be that it slows down the code -- at first I thought that didn't matter,
but someone made a good effort to make the existing code fast (possibly
to support cases where IndexError is used for control flow instead of
for error conditions).

I'm abandoning this one since I couldn't find a way to do it that didn't impair performance. Unlike C++, it is not uncommon in Python to use exceptions such as IndexError for control flow. There was too little added value in building-out this message to warrant the change (the current message is very clear about what the problem is, it just doesn't dump all the variables involved -- this is not uncommon for python error messages).