[PyKDE] KControl Modules II (Simon Edwards)

[Phil Thompson]

On Monday 05 January 2004 6:11 pm, Jim Bublitz wrote:
> 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.

Before Python 2.3 thread management was very difficult to get right, hence the 
guidelines in the PyQt documentation and the fact that SIP and Boost 
generated bindings don't mix well (because Boost knows nothing about thread 
states).

> > 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.
>
> From the KDE/PyKDE end, I need to look into this in more detail.
> I don't know Mark Hammond personally, but I've seen him on a few
> different lists and comp.lang.python, and he seems to be really
> helpful, so I appreciate the pointer. I really need to
> characterize the problem better and then probably get some
> assistance from Phil or someone like Mark - I just don't have
> enough info to ask the right questions at the moment, and
> haven't really looked into the obvious stuff in enough detail
> either.

Mark wrote and implemented PEP 311 which hugely simplifies things. SIP v4 uses 
the new API calls and it means SIP generated bindings will be much more 
robust when used in "non-normal" situations.

> In the meantime if someone wants to rework/replace libpythonize,
> I'm all in favor of that. I'm not eager to be the guy that makes
> this stuff work, but I'll get on it if no one else does.

I don't mind looking at this in a couple of weeks or so. I'd like to see a Qt 
wrapper around the Python interpreter - which I can then put a Python wrapper 
around.

Phil