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. >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. 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. Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
