Keyword arguments in slot handling and Trace Support

[Joerg Kreuzberger]

Hi!

In this thread (https://sourceforge.net/p/pythonqt/discussion/631393/thread/26038624/?limit=25#579d) we discussed about keyword arguments in slot calls.
I have now merged code changes relating to this to the trunk version. I also added a test for it.

The attached patch was made on linux.
The patch also includes some interface additions in PythonQt. These allow me to

• call PythonQt with an Py_TraceFunc to implement Tracing/Debugging Features
• call PythonQt with given globals() and locals()

For Multithread handling in my Trace/Debugging context i had to make no changes to PythonQt, i was able to handle multithreading (That means the Global PythonQt instance is used, and i can call Python Code via PythonQt in several QThreads) in my application layer.

Please consider integration in your trunk.

Thanks in Advance.

[Florian Link]

KW args look interesting, I will merge it when I find time. What is the rationale of the trace functions? Can't you just enable tracing from outside (at least we do that for our debugger), without patching PythonQt.

[Joerg Kreuzberger]

In my understanding the method to set the trace function
PyEval_SetTrace( Py_tracefunc func, PyObject obj)
required as second argument an PyObject. This object( in PythonQt Code called dict) is assigned in the evalScript Functions of PythonQt.
Therefore i thought i had to call the method with exactly this dictionary.

If you say it doesnt matter, then you are right, it is obsolete to have these functions and do it around PythonQt. At this point i do not understand the python docu clearly. But i could also imagine that the object* passed to the trace function is only there to maintain states between calls to the trace function and to "identify" e.g. different trace methods and objects in multithread call.

[Florian Link]

In our debugger we use:

PyEval_SetTrace(staticTrace, PyCapsule_New(this, NULL, NULL));

where this is our debugger instance.

[Joerg Kreuzberger]

i implemented like you suggested in your last mail, so it worked for me. The methods are already removed from my local pyhtonqt. So you can ignore them in the patch.

[Florian Link]

I refactored your kwargs code and committed it.

[Joerg Kreuzberger]

thanks. I take the new commit as base for the unicode refactoring to get rid of my actual source code patching. When is your next planned release?

[Florian Link]

I don't have plans for that, I have a very limited time budget right now (as you can see from not reacting on forums posts as quickly as usual).

[Joerg Kreuzberger]

ok. There was an interface change in my patches you didnt take over:
//! evaluates the given script code with given local and global environment and returns the result value
QVariant evalScript(const QString& script, PyObject globals = nullptr, PyObject locals =
nullptr, int start = Py_file_input );

Was there a special reason for that or could it be solved different?

[Florian Link]

I simply did not see that. Please provide patches only with single features, otherwise it is too tedious to merge.

[Joerg Kreuzberger]

ok, will do so :-)