Oh, nice. It is an interesting problem
Yes, I used to do Python inside Csound within Cabbage like this, but have changed my workflow in later years. I have the same needs still (need for some some operations that are much easier to do in Python than in Csound). Now I usually just run Python in its own procress, like a server running in the background, then I use OSC to send data from Csound, triggering some operation in Python that returns data over OSC to Csound. I run Csound within a VST with Cabbage.
One major reason for this architecture is that I wanted to de-synchronize the audio thread from the (possibly heavy) operations done in Python. If Python takes too long to complete an operation, and you use Python synchronized within Csound (like with the py opcodes) you get audio dropouts on your whole Csound orchestra. When I de-synchronze the processes, it might happen that the instrument needing Python will have a small lag in responsitivity, some latency before the Python calculations affect the output in the intended manner, but still making sound all the time, and even more importantly not creating dropouts for other instruments that run concurrently.
I also had some thoughts that perhaps the py opcodes would not be so easily compatible with future updates (of Csound and of Python), and thus they might be likely to break (e.g. when Python has a major version update, as happened not so long ago). When I run Python as a separate process, the architecture better separated in blocks and it is easier to debug compatibility problems (when coming back to it 10 years from now, and it won’t run).
I can send some (untidy) examples if anyone wants to see. I am sure it can be optimized, but the general signal flow works well.