Message102622
I just hit this one myself, and was about to write a bug and patch.
On reviewing the patch:
1. This really has the same issue as the original code: it detects one of a few known return values, and will infinitely loop on an unexpected return value. It would be better to explicitly check for 0 (continue), E_EOF (exit normally), and any other result (exit abnormally).
2. I don't think you want to unconditionally call PyErr_Print(), because you don't know for sure that an exception is set.
3. Returning 0 from PyRun_InteractiveLoopFlags() when an error occurs is a behavior change, which makes its documentation incorrect (meaning there should also be a doc patch). But to be honest, I don't think it's correct to return 0 in this case. It seems better to return the actual error code (which also requires a doc patch)
If you don't have time to update the patch, let me know and I'll put one together. |
|
Date |
User |
Action |
Args |
2010-04-08 15:35:11 | tlesher | set | recipients:
+ tlesher, vstinner |
2010-04-08 15:35:11 | tlesher | set | messageid: <1270740911.07.0.163247798403.issue8070@psf.upfronthosting.co.za> |
2010-04-08 15:35:09 | tlesher | link | issue8070 messages |
2010-04-08 15:35:08 | tlesher | create | |
|