Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @iritkatriel for commit bc889bc 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
There was a problem hiding this comment.
I noticed that in some places you require type and value to be both "nullish" or both "not nullish" (where "nullish" means either NULL or Py_None), and in other places (in particular in _assert_exception_type_is_redundant()) they are required to both be the same nullishness (i.e., both NULL or both Py_None or neither of them nullish). Is there a reason for the difference?
Sorry, something went wrong.
|
I noticed that in some places you require type and value to be both "nullish" or both "not nullish" (where "nullish" means either NULL or Py_None), and in other places (in particular in _assert_exception_type_is_redundant()) they are required to both be the same nullishness (i.e., both NULL or both Py_None or neither of them nullish). Is there a reason for the difference? Yes. Most of these assertions are verifying that the change right next to them is valid. So if I replace if(exc_type is nullish) by if(exc_value is nullish) then I only care that their nullishness is the same. In the case of the triplets pushed to the stack, it used to be that no-exc was pushed as "NULL, NULL, None" (None for type, NULL for value and tb). I change that in this PR (ceval.c lines 5907-9 sorry - 4182-88) so now it's "NULL, None, None". There are places where "None at the top of the stack" means there is no exc_info. So when we will remove the type we need the value to be None and not NULL, otherwise we'll get segfaults. |
Sorry, something went wrong.
There was a problem hiding this comment.
Okay, I'm through now. (Sorry for the premature send on the first batch.)
Sorry, something went wrong.
| @@ -586,7 +633,18 @@ _PyErr_ChainStackItem(_PyErr_StackItem *exc_info) | |||
| exc2 = exc_info->exc_type; | |||
There was a problem hiding this comment.
While you're here could you change 'exc' and 'exc2' to 'type' and 'type2' (or 'typ' and 'typ2')? It drives me nuts that we mix "exc[exption]" and "typ[e]" for the same concept (this must date back to Python 1 when the value was not an exception instance and the exception could be any object).
Sorry, something went wrong.
There was a problem hiding this comment.
All good! (Alas, I'm still stuck trying to wrap my head around the except* implementation, so that one will probably have to wait until next week.)
Sorry, something went wrong.
This brings us closer to removing exc_type from exc_info.
Where exc_type is used, I made it use exc_value instead and added assertions that this is ok. Then when we remove exc_type it will just be a matter of removing the assertions.
https://bugs.python.org/issue45711