[3.10] gh-91924: Fix __ltrace__ for non-UTF-8 stdout encoding#93214
[3.10] gh-91924: Fix __ltrace__ for non-UTF-8 stdout encoding#93214vstinner merged 2 commits intopython:3.10from vstinner:fix_lltrace_310
Conversation
Fix __ltrace__ debug feature if the stdout encoding is not UTF-8. If the stdout encoding is not UTF-8, the first call to lltrace_resume_frame() indirectly sets lltrace to 0 when calling unicode_check_encoding_errors() which calls encodings.search_function(). Add test_lltrace.test_lltrace() test.
|
@sweeneyde @serhiy-storchaka: Would you mind to review this fix for Python 3.10? The fix is different and I adapted the test from the main branch for 3.10. Without the fix but with the new test, |
|
I'm not sure why Windows CI is failing, the tests pass on my Windows machine. Maybe it has something to do with not calling |
In the 3.10 branch, the Windows CI builds Python in release mode. I fixed the test. |
|
@sweeneyde: the CI tests now pass. |
sweeneyde
left a comment
sweeneyde
left a comment
There was a problem hiding this comment.
Looks good to me. The local variable is nicer, but I agree that minimizing changes (EXT_POP and call_function) is more important.
Adding an argument to call_function() can make the performance worse, and the code more complicated depending if LLTRACE macro is defined or not. I really want to minimize the risk of regression in 3.10 stable branch. |
|
I hesitated to fix |
|
It reminds me the weird typo of |
|
Oh, for the float method, I backported my change fixing the typo: #31558 |
3 participants
Fix ltrace debug feature if the stdout encoding is not UTF-8.
If the stdout encoding is not UTF-8, the first call to
lltrace_resume_frame() indirectly sets lltrace to 0 when calling
unicode_check_encoding_errors() which calls
encodings.search_function().
Add test_lltrace.test_lltrace() test.