bpo-38530: Offer suggestions on AttributeError

[pablogsal]

https://bugs.python.org/issue38530

[pablogsal]

@serhiy-storchaka Would you like to take a look at this PR when you have some time? :)

[vstinner]

First review. I like the overall approach (I expect a low overhead when raising AttributeError).

[vstinner]

https://www.python.org/dev/peps/pep-0473/ was rejected because it was too broad, but this PR adds a single exception, which sounds ok according to the resolution: https://mail.python.org/pipermail/python-dev/2019-March/156692.html

My main worry is the risk of creating "more" and "worse" exception cycles, but Pablo says that it sounds unlikely: https://bugs.python.org/issue38530#msg354975

[vstinner]

Why not storing suggestions in a new Exception field, rather than replacing existing args? I may break some applications.

[pablogsal]

Because I don't want to touch the reporting facility to inspect said field or allowing users to inspect it manually

[pablogsal]

Also, this substitution only happens before printing the value because it has been not caught. Nobody should be able to inspect this exception later, no? Notice this only happens in the default exception display, so if someone has a custom handler, they will not see this AFAIK.

[methane]

Code level comment:
I don't understand why exc->args = new_args; Isn't it set by Py_SETREF?

Higher level comment:
Why do you replace exc->args instead of just printing suggestion after _PyErr_Display() or in _PyErr_Display()?

[pablogsal]

I don't understand why exc->args = new_args; Isn't it set by Py_SETREF?

I forgot to remove that after updated the code after @vstinner suggestions.

Why do you replace exc->args instead of just printing suggestion after _PyErr_Display() or in _PyErr_Display()?

Actually, this is a very good point, this can make the code cleaner. I will implement this