bpo-33159: Add name attribute to NameError

[sk-]

This is the first change to implement PEP 473.

The plan is to add the attributes described in the PEP one exeption at a time, adjusting the most common places where the exceptions are raised to also include the structured data.
Once the exceptions have been updated, the next step would be to update the Python code and the remaining places where exceptions are raised in the C code.

Note: This is my first PR to cpython, so if anything is amiss I would be happy to fix it.

See #81978, https://bugs.python.org/issue37797 and https://bugs.python.org/issue33159 for extra context.

https://bugs.python.org/issue33159

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

[eric-wieser]

Why msg and not message, which is the name for this property in python 2?

[sk-]

The structure of this exception was modeled after the current implementation of ImportError, which uses msg.

Note that the message attribute in exceptions have been deprecated since python 2.6 and has been removed in python 3. See PEP 352 for more details. I wonder though, why the msg attribute was added to ImportError.

That being said, I think that probably I just should remove the msg field.

Any thoughts?

[sk-]

Any chance this PR could be reviewed at all?

[corona10]

Looks like rejceted PEP ..

[sk-]

The PEP was rejected because it was deemed to be to broad (see https://mail.python.org/pipermail/python-dev/2019-March/156692.html):

The steering council felt the PEP was too broad and not focused enough. Discussions about adding more attributes to built-in exceptions can continue on the issue tracker on a per-exception basis (and obviously here for any broader points, e.g. performance implications as I know that has come up before when the idea of storing relevant objects on exceptions).

Should I open an issue in bpo, or should the discussion take place here?

[corona10]

@sk-
IMHO, This place is not the place for discussion about PEP.
You may propose a newly revised PEP which overcomes the last SC feedback.
But without the accepted PEP, this PR can not be merged.

[hugovk]

PEP 1 says where to discuss PEPs:

Posting to the Python-Ideas mailing list or the Ideas category of the Python Discourse is usually the best way to go about this, unless a more specialized venue is appropriate, such as Typing-SIG for static typing or the Packaging category of the Python Discourse for packaging issues.

So please open a discussion thread on Python-Ideas or Discourse.

And let's close this because PEP 473 was rejected.

[sk-]

@hugovk Note that although the PEP was rejected they mentioned

Discussions about adding more attributes to built-in exceptions can continue on the issue tracker on a per-exception basis

Issue that I created https://bugs.python.org/issue37797, #81978 and has not received any replies either.

Please reopen the PR or at least comment on the attached issue on why the change is not acceptable.

[hugovk]

Thanks, I hadn't seen that newer issue, re-opening!

[MaxwellDupre]

I don't think you should be mentioning 'PEP 473 Support' when it has been rejected. A bug report is ok. Also, need to re-target for 3.12.