[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

[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

[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

[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.

[issue33576] Remove exception wrapping from __set_name__ calls

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

[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