If you are implementing a COM object using win32com, then Python will
never be unloaded from the host process, which works in your favour.
Just have the COM object use a thread and a queue for this processing.
The 'report' method would just stick the params and filenames in the
queue and return immediately - your thread should stay alive and working
away so long as the host process remains alive. You probably need to
deal with the face the thread will be unexpectedly terminated when the
host process terminates or add a new method designed explicitly to block
the host process until everything is complete - the host program would
then call this method just before it terminates.
Also note there is a python-wi...@python.org mailing list where you
might get better or more advice...
Cheers,
Mark
On 8/12/2010 8:03 PM, kirby.ur...@gmail.com wrote:
Greetings gurus.
I'm faced with the challenge of having a single-threaded proprietary
Win32
language wanting to do multiple calls against a Python COM object.
Something like...
loObj = CREATEOBJECT("map_maker")
loObj.report( params, filename)
do while .True.
yadda yadda
enddo
RETURN
I.e. the client program continues execution while loObj churns away
somewhere doing work in Python, say accessing a MySQL database
and building a map, embedding it in a PDF.
Am I right that the COM object will need to "serve forever" i.e. be
built around some non-terminating loop? Will the client's call then
spawn a process or thread that continues until finished?
All it has to do is leave a file on disk somewhere, then die. But
the client can't be kept on the hook until that's all done.
I've had good luck doing an InProcess COM object the generates
a PDF from ReportLab. But this "stay alive while returning control
to the client" challenge looks like it might be a job for sockets?
Gee I hope not.
Quick links to favorite blog articles will give me a sense of the
ballpark... Any clues welcome. Yes, I have the Win32 book from
O'Reilly.
Kirby
PS: my thanks to Ethan Furman for performing maintenance and
upgrades on his dbf module on PyPI. The FoxPro gods thank you.
http://pypi.python.org/pypi/dbf/0.88.16
PPS: some thoughts about IronPython filed here, after trying to
catch up some, sorry about my formatting, here too.
http://mail.python.org/pipermail/edu-sig/2010-December/010138.html
--
http://mail.python.org/mailman/listinfo/python-list
