importing PySide6 or shiboken6 removes trace callback

bdieterm

Problem description

As far as I have seen, importing PySide6 or shiboken6 removes the trace callback function that was set via sys.settrace.
This happens with PySide6 6.8.x and Python 3.13 at least on Linux and MS Windows. The same PySide6 version but with Python 3.12 instead of 3.13 works fine (keeping the trace callback).

The following code demonstrates this:

import sys

def my_tracefunc(frame, event, arg):
    pass

sys.settrace(my_tracefunc)

import shiboken6  # or import PySide6

func = sys.gettrace()
print(f'{func is my_tracefunc = }')
print(f'{func is None = }')

"""
results with PySide6 6.8.0.2 and Python 3.12:
func is my_tracefunc = True
func is None = False

results with PySide6 6.8.0.2 and Python 3.13:
func is my_tracefunc = False
func is None = True
"""

Implication: Debugging does not work anymore

After the shiboken6 or PySide6 import removed the trace function callback, debugging does not work anymore.

To see this, first create a script, for example with the name aa.py:

breakpoint()
print('before import shiboken6')
import shiboken6  # or import PySide6
print('after import')
print('finished ')

Then run this script by passing the filepath to the Python interpreter in a terminal, e.g. python3 aa.py.
The breakpoint() call will automatically enter Pdb.
By entering the command n the debugger continues execution till the next line. Do this multiple times and observe what happens.

The problem is that executing till the next line does not work anymore after the import shiboken6 statement.
When using the combination of PySide6 6.8.x and Python 3.13, then the problem occurs, but not when using Python 3.12.
This happens on Linux as well as MS Windows. I have no macOS computer to test this there as well.

The reason for the debugger to not stop anymore is that the trace callback function is removed by shiboken6. The following example demonstrates this by making a backup of the trace function and restoring it after the import. Then debugging works normally again:

import sys
breakpoint()
print('before import shiboken6')
t = sys.gettrace()
import shiboken6  # or import PySide6
print('tracing is not active here anymore')
sys.settrace(t)  # restore tracing
print('after import')  # tracing works again
print('finished ')

Question

For me, this looks like a bug, most likely in shiboken6 and less likely in Python 3.13.
Or is there another explanation?

JonB

You are likely to need to report this at https://bugreports.qt.io/

friedemannkleint

PySide does not call sys.settrace() nor PyEval_SetTrace() by itself, and also has no Python 3.13 specific handling in this area. So, it is a bit of a mystery.

JonB

@friedemannkleint
But maybe PySide/shiboken does something "low level" which could (inadvertently) affect trace information? Though quite why OP reports that importing either one messes it up is perhaps "surprising".

As a thought: if, for whatever reason, the change in Python version leads to some error in low level code PySide/shiboken, maybe that could cause the broken sys trace? It might not report an error when trying to evaluate sys trace stuff?

I have had a scroll through https://docs.python.org/3/whatsnew/3.13.html, but nothing special struck me. You of course may know better.

I would think the first thing is to see whether you/another user has the same issue with the same version of Python/Qt/PySide/shiboken as the OP. I do not have these, and am only an infrequent Python user.

bdieterm

I did some further analysis of the problem and I found the root cause.

This is indeed a shiboken6 bug.

The shiboken6 module causes an infinite recursion with the overloaded import function.
In Python 3.13, some imports were moved inside a function which then closes that recursion loop.
You can easily reproduce this in Python 3.12 by inserting the line import os here.

I already created an issue with some further information (PYSIDE-3054).

ctismer

@friedemannkleint Not a mystery any more. The tracing of Py 3.13 does an import in the context of my feature callback that was not expected.
@bdieterm The fix was straight forward: Not only call the original import but temporarily reset the whole import machinery to its original state.

The fix is submitted and waits for approval. Thanks for finding this :)

bdieterm

@ctismer
Thanks for fixing the problem.