[PyKDE] KControl Modules II (Simon Edwards)

Jim Bublitz 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
> 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 been
> called.

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 
properly either.

> afaik little has changed since Mark Hammond wrote this:
> http://mail.python.org/pipermail/thread-sig/1999-March/000305.
>html

> 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 mailing list