Give IndexError an index attribute to store the index it was raised for. Since it is typically an integer there is no reason to worry about GC and thus using a regex.

regex?  do you mean weakref?

Yes, I mean weakref.

Is there a meta-issue for these changes?
I remember a similar discussion a couple of years ago, but I don't remember if it was on python-dev/ideas or on the bug tracker.
I agree that exceptions could be improved, but I would like to get the big picture of the changes you are planning to do instead of many individual issues.  A simple PEP might also be good, depending on how far you want to go :)

Nope, no meta-issue. I literally just realized one evening that the handful of exceptions that I filed bugs for could use an attribute for why the exception was raised.

I would also like to see a PEP or good python-dev discussion before embarking on all these API expansions.  There should be an evaluation of whether any existing code would benefit from it, whether the current "args" attribute is sufficient, whether the code bloat is worth it, etc.

Also, I'm unclear on whether you expect users to have to provide the index value in their own code (i.e. is "raise IndexError" to still be permitted or will all pure python code be required to use "raise IndexError(i)" and change existing code if they already use "raise IndexError("Out of range")).

If you don't change requirements for pure python code, then how can be even rely on the new attribute being there (i.e.  is "except IndexError as e:  print(e.index)" guaranteed to work?).

Obviously it can't be required that the index be provided as that would break way too much code. There are already exceptions in the stdlib that have optional attributes you can choose to (not) set.

As for relying upon it, it would be just like any other object that gets a new attribute: either you rely on it because you know the code you are using always provides it (e.g. using core/stdlib code directly) or you use some way to deal with cases where it was not set (EAFP or LBYL). Subclassing IndexError to provide a inheritance guarantee that an attribute exists seems like overkill (e.g. IndexError2 so you can do ``except IndexError2 as exc:``).

-1 on expanding the API for an attribute that is sometimes there and sometimes not.  This doesn't add any value, but it does add complication.

Do you mean "sometimes there sometimes not" because old code won't set it (yet) or because you don't think it will always be appropriate to set the attribute and thus people won't set it when available?

I am in favor of adding meaningful attributes to stdlib exceptions.  I've always considered the lack of such an API a wart in Python, though an understandable one (since exceptions started out as simple strings).  But yeah, while I hate to say it, this is probably mini-PEP material :(.

See also issue1534607.

Since #21911 has been merged into this issue, I'd like to add: Please also include the length of the sequence in the exception message. It can help with debugging.

Knowing the len of the sequence would also be useful.
Brett, were you also planning to use these attributes in the error message (when they are available), or do you prefer to keep the two issues separate and reopen #21911?

> Is there a meta-issue for these changes?

FTR the other relevant issues are:
  #18156: Add an 'attr' attribute to AttributeError
  #18163: Add a 'key' attribute to KeyError
  #18165: Add 'unexpected_type' to TypeError
  #18166: 'value' attribute for ValueError

Part of the point of these various attributes I proposed was so that a good default message could be provided when only the new attributes are given. So I'm fine with that being part of this issue.

I'm working on this now (patch hopefully coming soon), and I've hit an interesting issue:
PySequence methods take care of negative indexes by adding +len before calling the subclass method (s.t. -1 becomes len-1 etc.). This means that if the subclass raises an exception with the index, it might be the wrong index.

This case only happens when index < -len, so when I talked it out with Larry he suggested just passing the original index to the subclass in this case. So for index >= 0 or index < -len the subclass will receive the actual index, and for -len <= index < 0 the subclass will get index+len.
That's a change in behavior, but I actually think it's a good one. The negative-index use case in PySequence is exactly intended for this [-len, 0) use case, and if some subclass wants to do something weird with negative indexes it'd probably want the actual argument anyway.

I'm writing my patch with this in it, but it might be worth discussing here if someone disagrees.

Looking forward to your patch Ofer! Thanks for working on this!

See also #1182143.

And PEP 473.