[PyKDE] KControl Modules II (Simon Edwards)

[Jim Bublitz]

On Monday January 5 2004 12:05, Phil Thompson wrote:
> 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/000
> > >305. 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.

Thanks - I'll check that out. I'd prefer to cut off (backwards) 
at Python 2.3 and sip 4.

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

It'll be a few weeks before I can look at it (this week ends 
tomorrow for me).  libpythonize is pretty trivial and is simply 
a C++ wrapper for the interpreter - I'm not sure what else you'd 
want to make a "Qt wrapper" (some interface to Qt threading?).