[issue33576] Remove exception wrapping from __set_name__ calls

Carl Meyer added the comment: Awkwardly, the motivating use case in issue21145 is a TypeError that we wanted to raise within __set_name__, and not have replaced. It feels a little ugly to special case TypeError this way. I like the _PyErr_TrySetFromCause idea. That function is a bit ugly too

[issue33576] Remove exception wrapping from __set_name__ calls

Serhiy Storchaka added the comment: Unconditional replacing an exception is bad, because it can hide important exceptions like KeybordInterrupt or MemoryError. What if raise a new exception only if TypeError was raised? This will cover the case of a __set_name__() method with wrong signature.

[issue33576] Remove exception wrapping from __set_name__ calls

Nick Coghlan added the comment: Hmm, I wonder if the UX problem with the current chaining might be solved in a different way, by doing something similar to what we did for codec exceptions (where we want to try to mention the codec name, but also don't want to change the exception type, and w

[issue33576] Remove exception wrapping from __set_name__ calls

Carl Meyer added the comment: Nick, I think the reason this exception wrapping was added is because the stack trace for these exceptions is currently a bit lacking. The "caller" for the `__set_name__` function is the `class` line for the class containing the descriptors. For exceptions raise

[issue33576] Remove exception wrapping from __set_name__ calls

Change by Carl Meyer : -- keywords: +patch pull_requests: +6637 stage: needs patch -> patch review ___ Python tracker ___ ___ Python-

[issue33576] Remove exception wrapping from __set_name__ calls

New submission from Nick Coghlan : Type creation currently wraps all exceptions raised by __set_name__ calls with a generic RuntimeError: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L7263 Unfortunately, this makes it difficult to use __set_name__ for descriptor validati