[PyKDE] KControl Modules II (Simon Edwards)
tdickenson at devmail.geminidataloggers.co.uk
Mon Jan 5 09:56:01 GMT 2004
On Saturday 03 January 2004 19:28, Jim Bublitz wrote:
> Basically maintaining a thread state variable along with the
> global interpreter lock in the interface to the interpreter. It
> appears to work when the Python interpreter is loaded from a
> plugin (as panel applets or control modules would do), but has
> problems from a Python program: for example, if you wrote a
> PyKDE program that loaded a KPart, and the KPart later tries to
> load the Python interpreter (which is already running) say to
> load another plugin, thread state issues arise again.
The python COM support on windows has to address the same problem. An
in-process python COM server has to create the python thread state... unless
it is being loaded into a python program.
In that case the solution involves having the 'pythoncom' extension module
track the python thread state. The COM activation machinery assumes that a
pre-existing thread state exists if that extension module's init function has
afaik little has changed since Mark Hammond wrote this:
That all seems to work in practice, but it is brittle. It assumes that all
python programs that eventually activate a python COM component will have
imported pythoncom. It would be really nice to have a solution to this
problem that worked across component technologies.
More information about the PyQt