[PyKDE] KControl Modules II (Simon Edwards)
jbublitz at nwinternet.com
Mon Jan 5 19:26:01 GMT 2004
On Monday January 5 2004 00:54, Toby Dickenson wrote:
> 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
> 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 been
I've tried (had other people try actually) making the same
assumption, more or less. Didn't seem to work at the time, but
it may be something related to sip, and it may have changed with
sip 3.9 or 4.0. At the time it seemed like there wasn't a
pre-existing thread state to get, but I may not have gone at it
> 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.
Either that, or the individual solutions should each be
sufficiently transparent that it makes no difference to the
application programmer which component technology he/she uses.
More information about the PyQt