debugpy holds object references for too long, causing eWasOpenForWrite errors.

[gswifort]

I've noticed several times in my code that eWasOpenForWrite errors occur during debugging sessions, which don't occur during normal execution. Analyzed cases show that scopes are being used correctly and objects should be closed. I haven't been able to achieve similar behavior with a simple example (which may mean I have a bug in my code).
Here's how I handle this:

try:
    import debugpy

    DEBUG_SESSION = debugpy.is_client_connected()
except ImportError:
    DEBUG_SESSION = False

# (...)

if DEBUG_SESSION:
    bref.dispose()

I know I could just always use .dispose(), but if DEBUG_SESSION clearly shows why .dispose() is used here.

Perhaps you have some ideas what could be the reasons for this or other better solutions.

[CEXT-Dan]

Interesting, I hardly use debugpy as I usually debug inside the wrapper with C++ debugger. There’s a lot of moving parts internally, there’s a ref count in Python, but also a ref count in PyRx, for cases like this. There’s two separate objects in Python, but one object with a ref count of two in PyRx.

        l1 = Db.Line()
        l2 = Db.Line.cast(l1)

If debugpy is holding a reference on the python side, there’s really no way for PyRx to see it. This must have been reported with other wrappers, maybe it would be reproducible with numpy.

I'll look at it

[CEXT-Dan]

There seems to be other reports of this as well, I posted links in #480