This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2016年04月25日 19:56 by Valentin.Lorentz, last changed 2022年04月11日 14:58 by admin. This issue is now closed.
| Messages (3) | |||
|---|---|---|---|
| msg264198 - (view) | Author: ProgVal (Valentin.Lorentz) | Date: 2016年04月25日 19:56 | |
In Python/errors.c, PyErr_Restore is defined this way: void PyErr_Restore(PyObject *type, PyObject *value, PyObject *traceback) In Python/ceval.c, in the END_FINALLY case, it is called like this: PyErr_Restore(status, exc, tb); I believe "exc" should be renamed to "val". Indeed, END_FINALLY pops values from the stack like this: PyObject *status = POP(); // ... else if (PyExceptionClass_Check(status)) { PyObject *exc = POP(); PyObject *tb = POP(); PyErr_Restore(status, exc, tb); And, they are pushed like this, in fast_block_end: PUSH(tb); PUSH(val); PUSH(exc); |
|||
| msg358716 - (view) | Author: Batuhan Taskaya (BTaskaya) * (Python committer) | Date: 2019年12月20日 16:22 | |
I am not sure if calls like this constitutes a problem. By the way most of the things changed in Python/ceval.c including removal of END_FINALLY (issue 33387) but calls to _PyErr_Restore is still there with that same arguments. |
|||
| msg358728 - (view) | Author: STINNER Victor (vstinner) * (Python committer) | Date: 2019年12月20日 19:10 | |
Variable names have no impact on the execution. Sometimes, it's called "exc", sometimes "val", sometimes "exc_val" :-) This issue is not a bug. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:58:30 | admin | set | github: 71032 |
| 2019年12月20日 19:10:58 | vstinner | set | status: open -> closed resolution: not a bug messages: + msg358728 stage: resolved |
| 2019年12月20日 16:22:44 | BTaskaya | set | nosy:
+ vstinner, BTaskaya messages: + msg358716 |
| 2016年04月25日 19:56:07 | Valentin.Lorentz | create | |