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?). >From an earlier discussion about generalizing application scripting, I'd like to have a sip-compatible, Qt-agnostic C++ layer and then any Qt-required stuff alongside or on top of that, even if it's all in a single lib. If you want to go from libpythonize, then I just need a good test case to work from. The QtDesigner stuff Roland Schulz was doing seems a like a good place to start, esp since it doesn't drag in extraneous KDE stuff, and produces something useful besides. I either have enough code from Roland already or can probably get the latest from him. On the other hand, if you want to start over from scratch and do something different, that's OK with me too. It isn't a lot of lines of code to write - they just need to be the right lines. I'd suggest whoever gets to it first just give everyone else a "heads-up". Like I said, I'm not obsessed with doing this, but I need it to work with some of the KDE/PyKDE related stuff (panel applets and all of David's stuff). Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
